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 UserCancelled 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.