Terminal-2 icon

Make a gift card payment

Make a gift card payment at the point of sale.

After you have activated a gift card and loaded with a balance, you can make a payment with the gift card. There are two gift card payment flows: one using partial payments and another that involves a balance check first.

Requirements

Before you begin, take into account the following requirements, limitations, and preparations.

Requirement Description
Integration type A Terminal API integration with payment terminals.
Setup steps Before you begin:

How it works

You can choose one of two payment flows:

  • A flow with one or more partial payment requests if you do not know the exact balance on the gift card:
    1. Make a partial gift card payment request for the full amount due.
    2. If the gift card balance is not enough, you make a follow-up payment request to let the shopper pay the remainder with another card or cash.
  • A flow without partial payments where you first check the balance of the gift card:
    1. Make a balance request to check the balance on the gift card.
    2. Decide what to do next:
      • If the balance is enough, you make a gift card payment request for the full amount due.
      • If the balance is not enough, you make a gift card payment request for the full balance, and then you make a regular payment request to let the shopper pay the remainder with a different card or cash.

1. Make the initial payment

Testing

You can test the partial payments flow using an amount ending in 139.

To make a payment using a gift card where partial authorization is possible:

  1. Determine the card entry method:

    • If you want to scan the card, do that first and use the obtained card details in your request.

    • If you want to swipe the card or use manual key entry (MKE), send the request first. The payment terminal will show a prompt to swipe the card or enter the card details.

  2. Make a PaymentRequest with:

    • SaleToPOIRequest.MessageHeader : The standard MessageHeader object, with MessageClass set to Service and MessageCategory set to Payment.

      Parameter Required Description
      ProtocolVersion -white_check_mark- 3.0
      MessageClass -white_check_mark- Service
      MessageCategory -white_check_mark- Payment
      MessageType -white_check_mark- Request
      ServiceID -white_check_mark- Your unique ID for this request, consisting of 1-10 alphanumeric characters. Must be unique within the last 48 hours for the terminal (POIID) being used.
      SaleID -white_check_mark- Your unique ID for the POS system component to send this request from.
      POIID -white_check_mark- The unique ID of the terminal to send this request to. Format: [device model]-[serial number].

    • PaymentRequest.SaleData. This includes:

      Parameter Required Description
      SaleTransactionID -white_check_mark- An object with:
      • TransactionID: your reference to identify a payment. We recommend using a unique value. In your Customer Area and Adyen reports, this will show as the merchant reference for the transaction.
      • TimeStamp: Date and time of the request in UTC format.
      SaleReferenceID Unique reference, such as your order number plus a sequence number, that lets you identify partial payments that belong together. In your Customer Area, this will appear as the Merchant Order for the transaction.

      For example, if the order number is Order12345, you specify Order12345-1 in the first partial payment request and Order12345-2 in the second partial payment request.
      SaleToAcquirerData -white_check_mark-
      • The AllowPartialAuthorisation tender option. See the instructions below.
      • Optional for manually keying in the card number (MKE): maxLength and cardMask. Use these fields to specify card numbers with more than 24 digits. See the example MKE gift card request.
      • Optional for Stored Value Solutions (SVS) gift cards: ssc. This is the secondary security code of the gift card, and allows up to 8 digits. For example, ssc: 1111.


      In SaleData.SaleToAcquirerData, specify the tender option in one of the following formats:

      • Option 1: a JSON object converted to a Base64 encoded string.
        Encode {"tenderOption": "AllowPartialAuthorisation"} to Base64, and pass the resulting string:
        "SaleToAcquirerData": "eyJ0ZW5kZXJPcHRpb24iOiAiQWxsb3dQYXJ0aWFsQXV0aG9yaXNhdGlvbiJ9"

      • Option 2: a key-value pair:
        "SaleToAcquirerData": "tenderOption=AllowPartialAuthorisation"

      The format that you use here will also be the format of the AdditionalResponse that you receive. If there are more tender options (for example, ReceiptHandler ) or other data elements that you need to pass in the SaleToAcquirerData field, refer to Add information to a payment.

    • PaymentRequest.PaymentTransaction. This includes:

      Parameter Required Description
      AmountsReq -white_check_mark- An object with:
      • Currency: The transaction currency.
      • RequestedAmount: The purchase amount, with decimals.

    • PaymentRequest.PaymentData.PaymentInstrumentData. This is where you indicate that a gift card is used.

      Parameter Required Description
      PaymentInstrumentType -white_check_mark- StoredValue
      StoredValueAccountID -white_check_mark- The gift card details:
      • StoredValueAccountType: GiftCard
      • StoredValueProvider: the gift card issuer, such as givex, svs, valuelink, genericgiftcard, or any Intersolve-supported card type.
      • IdentificationType: PAN
      • EntryMode, StoredValueID and ExpiryDate: these parameters depend on the card entry method you are using. See the following table.
      Card entry Parameters
      Scan
      • EntryMode: Scanned
      • StoredValueID: gift card number.
      • ExpiryDate: expiry date of the gift card.
      Swipe
      • EntryMode: MagStripe
      • StoredValueID: include this parameter but do not provide a value.
      MKE
      • EntryMode: Keyed
      • StoredValueID: include this parameter but do not provide a value.

    Select the tabs below to see some example gift card payment requests.

    See the PaymentRequest API reference.

  3. In the payment response, note the following:

    • Response.Result: If the payment was successful, Success indicates a full payment, or Partial indicates a partial payment.
    • PaymentResult.AmountsResp.AuthorizedAmount: The amount that was authorized. This may be less than the requested amount.
    • AdditionalResponse: Contains posOriginalAmountValue with the requested amount, and posAuthAmountValue with the authorized amount.
    • SaleData.SaleReferenceID: Your order number. If you are going to make another partial payment, the SaleReferenceID of that other payment must be based on this one.

    The example below shows that the gift card payment was successful, but only EUR 10.00 of the original EUR 25.99 was authorized.

    See the PaymentResponse.

  4. If the Response.Result is Partial, make a follow-up partial payment or let the customer pay the remainder in cash.

2. (Optional) Make a follow-up payment

If the initial partial payment with the gift card didn't cover the full amount, you can follow up with another partial payment for the remainder:

  1. Calculate the remaining amount after the initial partial payment: subtract the AuthorizedAmount in the response from the RequestedAmount in the request.
    Alternatively, you can calculate the remaining amount using posAuthAmountValue and posOriginalAmountValue from the AdditionalResponse.

  2. Make a PaymentRequest with:

    • SaleToPOIRequest.MessageHeader : The standard MessageHeader object, with MessageClass set to Service and MessageCategory set to Payment.

      Parameter Required Description
      ProtocolVersion -white_check_mark- 3.0
      MessageClass -white_check_mark- Service
      MessageCategory -white_check_mark- Payment
      MessageType -white_check_mark- Request
      ServiceID -white_check_mark- Your unique ID for this request, consisting of 1-10 alphanumeric characters. Must be unique within the last 48 hours for the terminal (POIID) being used.
      SaleID -white_check_mark- Your unique ID for the POS system component to send this request from.
      POIID -white_check_mark- The unique ID of the terminal to send this request to. Format: [device model]-[serial number].

    • PaymentRequest.SaleData. This includes:

      Parameter Required Description
      SaleReferenceID Unique reference, such as your order number plus a sequence number, that lets you identify partial payments that belong together.

      For example, if you specified Order12345-1 in the first partial payment request with the gift card, you'd specify Order12345-2 in this second partial payment request.
      SaleToAcquirerData -white_check_mark- The AllowPartialAuthorisation tender option.

      For the format, see the initial partial payment.

    • PaymentRequest.PaymentTransaction. This includes:

      Parameter Required Description
      PaymentTransaction.AmountsReq -white_check_mark- An object with:
      • Currency: The transaction currency.
      • RequestedAmount: The calculated remaining amount.

    This example shows a payment request for the remaining EUR 15.99.

  3. When you receive the response, check if the Response.Result is now Success. That means the amount due is paid in full.

Alternative flow with the balance check

In this flow you first check the balance on the gift card, and then adjust your payment request(s) accordingly.

To illustrate this, we use an example where the purchase amount is EUR 25.99, and the shopper has a gift card with a balance of EUR 15.99.

  1. Check the balance on the gift card. In our example, that is EUR 15.99.

  2. Make a gift card payment request for the available amount, EUR 15.99:

  3. Complete the payment by making a regular payment request for the remaining EUR 10.00, or by asking the shopper for the remainder in cash.

See also