When you make a Terminal API transaction from your POS app, the API response includes receipt data. This contains values you can add to the receipt that you print, show, or email to your shopper.
Standalone terminals are not integrated in a POS system. They have a built-in printer that automatically prints a compliant receipt.
Generating compliant receipts
Card schemes have very specific requirements on what should be included on a receipt. These requirements differ per scheme and country, and can change. Receipts generated by Adyen have been certified as compliant by the card schemes that we support.
We strongly recommend generating receipts using the Adyen-generated receipt data without alterations.
Card schemes will occasionally visit stores to verify that the receipts are fully compliant. Non-compliant receipts can result in payments being charged back.
If you override this receipt data, or validate values against a hard-coded list, it is your responsibility to ensure that scheme requirements are met at all times.
When you make a payment using our Terminal API, the payment result contains a
PaymentReceipt object. This object includes:
CustomerReceipt: you can use this data to generate a receipt for the shopper.
CashierReceipt: you can use this data to generate a merchant receipt. You can also use this data to collect the shopper's signature, or for reconciliation purposes.
Each receipt consists of multiple key-value pairs, which are generated dynamically depending on the:
- Transaction type.
- Result. For example, approved or declined.
- Cardholder verification method (CVM).
- Card issuer country.
- Country of your store.
- Payment method.
The following table shows all the keys that can appear in Adyen-generated receipt data.
|First header line of your receipt. You can customize this.
|Second header line of your receipt. You can customize this.
|Decline cryptogram generated by the card.
|Bank account used for the authorization. For example, chequing or savings account.
|Set of EMV details.
|Application Identifier (the scheme product).
|Final state for approved transactions.
|Final state for declined transactions.
|Final state for transactions that were cancelled by the merchant, shopper, or terminal.
|Application Transaction Counter.
|Authorization code from the issuer.
|Authorization response code from the issuer.
|Identification of the wallet used for authorization.
|Receipt type indicator. For example, CARDHOLDER COPY (or the localized text).
|Name of the cardholder. This key is not present by default. When enabled, it is included only on the merchant receipt. To enable this key, contact our Support Team.
|Terminal-determined value for the type of card.
|Amount to be provided to the shopper in cash.
|Amount donated to charity by the shopper.
|Cryptogram Information Data.
|Identification number issued for the National Registry of Legal Entities.
|Balance on the cardholder's bank account.
|When applicable, indicates the PIN has been verified.
|Explanation of the DCC process, for shopper consent.
|Markup on the sourced exchange rate for DCC.
|Exchange rate used to calculate the DCC conversion (including markup).
|Amount after DCC conversion was applied.
|Source of the base exchange rate (proxied by Adyen, excluding markup).
|Discount applied by the merchant.
|Expiry date of the card. If you want
|Generic filler to create blocks of elements that go together.
|Amount for gratuity.
|Merchant-determined reference for the transaction.
|Starting amount of the transaction before gratuity, adjustments, and such.
|The last four digits of the masked PAN.
|PAN sequence number or sequence number of the issued card.
|Payment method on the brand or scheme level, as provided by Adyen. For example,
|Payment method on the product level, as provided by Adyen. For example,
|Method of obtaining the PAN, such as ICC, NFC, MSR, or MKE.
|Issuer-determined label for the application on the card.
|Product used for paying, such as Credit or Debit.
|Hardware (terminal) identifier sent to the schemes.
|Retrieval Reference Number.
|System Trace Audit Number.
|Description of the token variant, such as ApplePay or SamsungPay.
|Total amount to be debited or credited.
|Terminal date of the transaction, in the local time zone.
|Reference for the transaction, provided by the merchant.
|Terminal time of the transaction, in the local time zone.
|Transaction type: GOODS_SERVICES, REFUND, and so on.
|Amount after DCC was applied by the scheme.
|Rate applied by the scheme to calculate DCC.
paymentMethod. For example,
|Reference that the scheme assigned to the transaction.
|Line to indicate a signature needs to be placed above it.
|Room for shopper signature on the merchant receipt.
|Line for merchant signature on the shopper receipt.
|'Thank you' message (or the localized text).
|QR code value. You can customize this.
If the Terminal API request includes characters from a non-Latin script, those characters are URL-encoded. To ensure those characters appear correctly on the printed receipt, you first need to URL-decode the
PaymentReceipt object from the payment response.
Displaying virtual receipts
Terminals with a built-in printer
You can optionally add your company logo to this receipt.
If you don't want to print the receipt on the terminal, specify the tender option ReceiptHandler in your payment requests. Without that tender option, a terminal with a built-in printer will print the receipt. With that tender option, a terminal with a built-in printer will not print the receipt. You can then let your POS app send the receipt data to your receipt printer, or email the receipt to the shopper.
To let the shopper decide whether to print the receipt:
In your Customer Area, go to In-person payments > Terminal settings > Receipts and enable Prompt before printing. The terminal will then show a screen like the following after a transaction.