Knowledge Base Testing & Certification Tools

Implementation Requirements

Genius Implementation Requirements

The certification of Point of Sale applications with our Genius API is essential at ensuring a seamless experience during the checkout process, for both merchants and their consumers. The purpose of the Genius Implementation Review, is to perform additional testing outside of what is listed on the Certification Test Script, and to ensure the Point of Sale application can properly handle certain scenarios.

Consumer-Driven Payment Selection

Traditional Point of Sale systems typically require that cashiers select a form of payment, or card brand, to be used prior to payment collection. With Genius, there is no need to select the form of payment or card brand being used. Genius will automatically determine the payment type and card brand used by the consumer at the time of the transaction.

The purpose of this requirement is to ensure that the cashier has a generic ‘Tender’ button that will be used to initiate a transaction to Genius. If individual tender buttons for the card brands are used within the Point of Sale, it presents a situation where transaction data may be inaccurate. For instance, if a cashier selects 'Amex' as the form of payment, and the consumer uses a 'Discover' card to complete the transaction, we will return <paymenttype>DISCOVER</paymenttype> within the response. The ideal configuration would be to have a single tender button which triggers initiating the transaction.

Cancel Requirements

When a transaction has been initiated to the Genius device, there may be times when it needs to be cancelled. Whether due to an error in the total amount or a consumer wishing to add or remove items, the cancel function can be used to cancel the transaction in progress. Additionally, the cancel request may be used to return the Genius device back to the idle screen in certain instances. Cancelling of a transaction can occur either by the consumer, or the merchant (cashier). In both instances, the proper response needs to be handled by the Point of Sale, and properly displayed onscreen to avoid confusion.

Merchant Cancel:

The Point of Sale must have the option to cancel a transaction in progress. This process requires no interaction with the consumer, and the Point of Sale must handle the response accordingly, and ideally, display the response onscreen. A status response of <status>POSCancelled</status> is returned.

Consumer Cancel:

The Point of Sale must acknowledge when a consumer has cancelled a transaction in progress from the Genius device. Once a transaction has been initiated to Genius, the consumer can press the Red X button on the keypad and confirm they wish to cancel the transaction. When confirmed, a status response of <status>UserCancelled</status> is returned.

Cancel on Signature Screen:

In the event a consumer completes their transaction without supplying a signature, the Point of Sale may utilize the cancel function to return the device back to the idle screen. In this scenario, the Point of Sale must acknowledge the results of the transaction, as they are returned in the TransactionResult details. It is important that this information is captured by the Point of Sale, and treated as an approved transaction rather than being dismissed due to the Point of Sale issuing the cancel request. Additionally, the <errormessage>APPROVED_No_Signature</errormessage> response will be returned if the consumer fails to supply a signature, before the screen times out and returns to the idle screen on its' own.

Accuracy of Historical Reporting

Historical reporting within the Point of Sale must reflect the payment type / card brand accepted through Genius at the time of the transaction. Genius returns the payment type and card brand used by the consumer at the time of the transaction, and this information should be reflected accordingly.

Transaction Amount Recognition & Amount Details Tags

The response from the Genius device contains detailed information about the payment processed. This information is sent back in a set of tags housed within the Amount Details tag. It is important the Point of Sale recognizes when values are returned within these tags, and properly handle the total amount returned, even if that amount is not equal to the original requested amount. The additional fields which could contain amounts are as follows: User Tip and Cashback.

In the event that either of these fields are triggered, the amount returned will not match that of the original requested amount. The Point of Sale must be able to prompt the cashier to act appropriately in the event of these situations.

User Tip:

If configured, Genius can display an onscreen prompt for the consumer to add a tip to their transaction. This is independent from any tip processing done within the Point of Sale after the transaction is completed. The Point of Sale must recognize this additional amount as a tip.


If configured, Genius can display an onscreen prompt for the consumer to request cashback during a debit transaction. The Point of Sale must indicate to the cashier, after the completion of the transaction, that cash back is due.

Partial approval and Over tender

During the checkout process, consumers may choose to use more than one form of payment to complete a transaction. For example, if a consumer is paying with a Stored Value card, and the balance due exceeds that of the available balance on the card, a Partial Approval will be issued. Genius will acknowledge there is a remaining balance due, display this information on-screen, and return this information back to the Point of Sale. The Point of Sale must acknowledge a balance due, and alert the cashier that additional payment is required to complete the transaction.

Just as Genius can acknowledge a partial approval and return the appropriate response back to the Point of Sale, Genius can also handle instances where the amount approved is greater than the initial amount requested. Over tendering should not be considered the same as a consumer selecting Tip or Cashback on the device. Over tendering would usually occur when consumers pay with a mobile payment, wherein they are able to apply gratuity, as an example, within the mobile app itself rather than on the Genius device. During implementation, we will ask that you test out both use cases, so that we may validate the Point of Sale is handling the responses accordingly, and providing guidance as to best practice on how to handle these scenarios.

Checkout Implementation Requirements

The Certification Engineering team will perform several checks against the online store / solution being certified, in an effort to ensure specific items have been implemented and meet our best practice standards. It is important to understand that while we've included a number of website security best practices to help you meet your security obligations, the items we look at do not place any obligation of PCI-DSS / PA-DSS on us. As a provider helping merchants accept payments, or a merchant building your own checkout integration, you are still in scope for the requirements and obligations of PCI-DSS regardless of any technological solutions you may implement.

SSL Server Test

We will run the domain through Qualys SSL Server Test and specifically, will be looking for the following:

Overall Grade:

The overall grade after running the test should be a B or above.

  • Certificates should not be, or have been revoked previously
  • Certificates should not be set to expire anytime in the near future, such as 2 weeks
  • No insecure protocols such as SSLv2, SSLv3, TLS 1.0
  • We will require TLS 1.1 or later
  • No weak cipher suites, or vulnerable, insecure protocol details
  • Server Key should be at least RSA 2048 bits or above
Autocomplete setings:

We will check to ensure any form fields that may contain sensitive data are configured with AUTOCOMPLETE="OFF". These fields may include:

  • Login fields such as Username and Password
  • PAN / CVV / CSC fields
Protection against Phishing:

If gift card balance inquiries are implemented, they must be adequately protected to protect against phishing attempts, such as submitting several balance inquiries in the hopes of finding cards that have outstanding balances. At least one of the following must be implemented:

  • Fields are protected by a Captcha
  • Fields reside behind a login form
  • Rate of inquiries are limited by IP Address
Additional Items:
  • Is the site HSTS enabled
  • Checking Cross-Domain policies
  • Prevents being hosted inside of a frame
  • Ensuring sensitive data is not stored in cookies