Outlines passing tender options (settings that change how a transaction is processed) with a
PaymentRequest and things to consider when using them.
Tender options can be used to modify your payment request. Tender options are passed to the Terminal API using the
Tender options are passed with a regular
PaymentRequest in the same way as making a basic payment. A
PaymentRequest can include additional form-encoded key-value pairs in the
SaleToAcquirerData field. This can include data to create recurring contracts.
Pass tender options in TransactionConditions
Some tender options can be expressed the The Terminal API directly using
ForceEntryMode, passed in
- If ForceEntryMode is absent, the default entry modes are used.
- If the list includes "Keyed", the terminal will trigger Manual Keyed Entry processing.
- If the list includes "MagStripe", magstripe is used as the POS entry mode.
- If the list does not include "Contactless", contactless will be disabled as a POS entry mode and no contactless option will be presented.
Pass tender options in SaleToAcquirerData
The fields described below are the basic payment fields you specify when making a
PaymentRequest call to the Terminal API as well additional tender option fields passed in
AllowPartialAuthorisation- Flags that a partial approval is allowed. As a result, the authorised amount might be lower than the requested amount.
AskCharity- Triggers the terminal to ask if the shopper wants to donate to charity.
AskGratuity- Triggers the terminal to ask if the shopper wants to tip.
BypassPin- Bypasses PIN entry where the shopper does not know the PIN for the card and the Merchant either knows they are the legitimate cardholder or wants to give them the benefit of the doubt.
ForcedDecline- Forces a decline of the transaction, for example, if fraud is suspected.
ReceiptHandler- Specifies that the POS handles and prints receipts. If omitted, it is required that the PED prints the receipt. If there is no printer unit, the transaction will fail.
For more information on the fields required for receipts, see Receipt requirements for card schemes.
MOTO- Triggers MOTO transactions on the payment terminal from the Cash register. MOTO transactions are card-not-present transactions, where the payment details are presented to a merchant by a shopper by means of mail (not email), fax, or telephone.
SkipAIDPriority- Skip a card's application identifier (AID) priority. This allows a shopper to select their preferred card application.
For a list of Payment Response fields, see PaymentResponse fields.
An authorisation is attempted and you receive a response with the following fields:
Keyed ForceEntryMode response
If you receive an error, you may need to troubleshoot accordingly. For more information, see Error Scenarios.
Warnings are triggered when non-fatal errors occur. These are returned for your information in the response.