Add information to a payment

A basic Terminal API payment request includes the amount, currency, ID, and timestamp of the transaction. But maybe you want to add information that you want us to apply to your request, or save on the Adyen payments platform. The SaleToAcquirerData field allows you to do that. In this field you can add all kinds of data elements:

• Application info that we can use for troubleshooting purposes.
• Metadata of your own choice that you want to connect to the payment.
• Data to use for shopper recognition and tokenization.
• Dynamic shopper statements.
• Split payment details.
• Tender options to influence how the transaction is processed.
• Additional data for common use cases like pre-authorization, or hospitality.

Refer to the sample collection of SaleToAcquirerData to see what these data elements look like. Below we describe them in a bit more detail, and we explain how to add a combination of data elements to your payment request.

Application info

Application info consists of data elements that identify the software that you use for making payment requests to the Adyen payments platform. When you pass this information in your payment requests, we are able to analyze and troubleshoot payments more efficiently, and provide a better support experience.

For details, see Pass application info.

Metadata

Metadata are data elements that you create yourself. When you add metadata to your payment request, they are returned in the response so that you can connect the transaction to your metadata. For example, to add a shift number and an employee ID to a payment. You are free to create up to 20 metadata fields, where the maximum field name is 20 characters, and the maximum value 80 characters.

To also receive metadata in your settlement reports, contact our Support Team.

Shopper recognition and tokenization

Based on shopper identifiers that you receive in your payment response, you can link the payment to a shopper. This enables you to personalize the shopping experience or make recurring payments using a token instead of real card details. But first you need to create those shopper identifiers and store them on the Adyen payments platform. To do so, you include data elements like shopperEmail, shopperReference, and recurringContract in the SaleToAcquirerData field of your initial payment request.

For more information see Shopper recognition.

Shopper statement

When shoppers check their bank statements, they need to be able to easily identify the charges they see. The description of the transaction should start with your brand or the merchant name that is most recognizable to the cardholder.

In your Terminal API payment request, you can provide a transaction-specific shopperStatement. We recommend sending no more than 22 characters and using only a-z, A-Z, 0-9, spaces, and the special characters . , ' _ - ? + * /. That is because banks may cut off longer statements and do not always support Unicode characters.

The shopperStatement from your Terminal API payment request only appears on your shopper's bank statement if your account is configured to include a dynamic shopper statement in the transaction description.

Split payments

Platforms usually split payments between the platform and the users of the platform. Using the SaleToAcquirerData field you can define how to split a payment, such as the amount and type of each split and the accounts that receive the splits.

For instructions, see our Adyen for Platforms documentation about processing in-person payments.

Tender options

Tender options are parameters that change how the tender is processed. For example, the tender option AskGratuity triggers the payment terminal to ask the shopper for a tip.

Additional data

There are many additional data elements that you can add to your payment requests. The list is long and growing, so we cannot mention all of them here. See for example the Additional data in our API Explorer. Many of these elements also apply to point-of-sale payments.

Adding data elements to your request

There are two ways to pass data elements in the SaleToAcquirerData field of your payment request:

• Option 1: as a JSON object converted to a Base64-encoded string.
• Option 2: as form-encoded key-value pairs (using & as a separator).

Refer to the sample collection of SaleToAcquirerData to see what these formats look like.

Receiving the additional response

The AdditionalResponse in your payment response returns information resulting from the processing of your payment request. It also returns some of the information you added to your payment request, so you can use this in your business logic.

The additional response can contain many data fields, but you may not need them all. To select the data that you want:

1. In your Customer Area, go to Developers > Additional data.
2. Select the options for the type of data you want to receive.

The format of the AdditionalResponse corresponds with the format of the SaleToAcquirerData in the payment request: a Base64-encoded JSON object, or form-encoded key-value pairs.
If the request doesn't contain any SaleToAcquirerData, the AdditionalResponse will be in key-value pairs format.

Option 1: Pass data elements as Base64-encoded JSON

This example shows how to add data elements to your payment request as a JSON object converted to a Base64-encoded string:

1. Create a JSON object with the data elements you want to pass.

   In this example, we use a limited set of data:

   • Metadata: the key employeeNumber with a value of 1
   • Shopper statement: Book shop - ISBN 9780706414004
   • Shopper email: S.Hopper@example.com
   • Shopper reference: CUST01_34582
   • Two tender options: ReceiptHandler to let the POS app handle printing or sending the receipt, and AskGratuity to ask for a tip.

   So the JSON object looks like this:

2. Encode the JSON object to Base64.

   ewogICAibWV0YWRhdGEiOnsKICAgICAgImVtcGxveWVlTnVtYmVyIjoiMSIKICAgfSwKICAgInNob3BwZXJTdGF0ZW1lbnQiOiJCb29rIHNob3AgLSBJU0JOIDk3ODA3MDY0MTQwMDQiLAogICAic2hvcHBlckVtYWlsIjoiUy5Ib3BwZXJAZXhhbXBsZS5jb20iLAogICAic2hvcHBlclJlZmVyZW5jZSI6IkNVU1QwMV8zNDU4MiIsCiAgICJ0ZW5kZXJPcHRpb24iOiJSZWNlaXB0SGFuZGxlcixBc2tHcmF0dWl0eSIKfQ==

3. Make a payment request with:

   • SaleData.SaletoAcquirerData: the Base64-encoded JSON object.

   Note that the payment response has an AdditionalResponse in the same format as the SaleToAcquirerData field: a Base64-encoded string.

4. Decode the Base64 string in the AdditionalResponse field of the payment response. This contains:

   • The metadata, shopperEmail, shopperReference, and shopperStatement from the request.
   • Data resulting from the processing of the payment. The shopper gave a 10% tip (EUR 1.09).

Option 2: Pass data elements as key-value pairs

This example shows how to add data elements to your payment request as form-encoded key-value pairs.

1. Create a string with the data elements you want to pass in key-value pairs, using & as a separator between the pairs.

   In this example, we use a limited set of data:

   • Metadata: metadata.employeeNumber=1
   • Shopper statement: shopperStatement=Book shop - ISBN 9780706414004
   • Shopper email: shopperEmail=S.Hopper@example.com
   • Shopper reference: shopperReference=CUST01_34582
   • Two tender options, to let the POS app handle printing or sending the receipt, and to ask for a tip: tenderOption=ReceiptHandler,AskGratuity

   So the string looks like this:

   metadata.employeeNumber=1&shopperStatement=Book shop - ISBN 9780706414004&shopperEmail=S.Hopper@example.com&shopperReference=CUST01_34582&tenderOption=ReceiptHandler,AskGratuity

2. Make a payment request with:

   • SaleData.SaletoAcquirerData: your string of form-encoded key-value pairs.

   Note that the payment response has an AdditionalResponse in the same format as the SaleToAcquirerData: form-encoded key-value pairs. This contains:

   • The metadata, shopperEmail, shopperReference, and shopperStatement from the request.
   • Data resulting from the processing of the payment. The shopper gave a 10% tip (EUR 1.09).

See also