Terminal-2 icon

Shopper loyalty

Use shopper recognition for loyalty purposes.

  Postman collection

Implementation examples
  .NET

With Adyen, you can set up a loyalty program where shoppers do not need to have a physical loyalty card. Instead, you identify shoppers based on payment data that you receive in card acquisition and payment responses.

If you recognize a shopper based on the payment data, you can offer tailored benefits like discounts, or make product recommendations based on their purchase history. If you do not recognize a shopper, you can enroll them on the spot using the payment terminal.

To use this method, you need to create customer profiles in your back-end system. A customer profile should contain the payment data that you use to identify the shopper, together with any other details that your use case requires, such as purchase history data.

For instructions, select the payment data that you want to use for identifying shoppers:

Card and shopper identifiers

You can use the card alias to recognize the shopper's card. But you can also go one step further and create your own identifiers to be returned in card acquisition and payment responses. That enables you to identify an individual, not just their payment card, and make the shopping experience more personal.

To be able to personalize the shopper experience, save the following identifiers:

  • Card alias (alias): a value that uniquely represents the shopper's card number (PAN), for example A37317672402294. With this, you can recognize the card that a shopper is using. You cannot use the card alias for making payments. You receive the card alias in the AdditionalResponse.
  • Shopper reference (shopperReference): this is your reference to identify the shopper. You submit it with a payment, and receive it back in the AdditionalResponse for that payment and also for any later card acquisition and payment responses.

    To get the shopper reference, you need to enable receiving this identifier.

  • Shopper email (shopperEmail): you collect the shopper's email address in some way, and submit it with a payment. You receive it back in the AdditionalResponse for that payment and also for any later card acquisition and payment responses.

Shopper consent and PIN entry

To save a shopper profile in your back-end system and to save the shopper reference and email on our platform, you need to ask the shopper for their consent.

We only save the shopper reference and email if your initial request also contains the recurringContract flag. This flag triggers the terminal to ask the shopper to authenticate by entering their PIN. Because there are still cards being used that do not have a PIN, our Support Team can disable asking for a PIN when the recurringContract flag is set. However, it goes against best practices to set this flag for every transaction.

Requirements

  1. Enable receiving shopper identifiers.
  2. Ask our Support Team to check that your account is correctly configured for your loyalty use case.

Synchronous flow

The synchronous flow allows you to actively engage the shopper on the spot. For example, if you recognize the shopper from a card acquisition, you can apply a discount or offer to redeem loyalty points before making the payment.

  1. Make a card acquisition request to check whether the shopper is recognized.
  2. If the card acquisition response indicates the shopper isn't known yet, create a new customer profile and make a payment. To ask the shopper's consent and gather the data for the customer profile, you can make input requests.
  3. If the card acquisition response indicates the shopper is already known, optionally make input request to communicate with the shopper, and then make a payment for a recognized shopper.

Check whether the shopper is recognized

When the shopper makes a purchase, first check if you already know the shopper. If you are in Estonia, choose the Estonian ID card check tab below to learn how to identify the shopper with their national ID card.

Create a new customer profile and make a payment

When the card acquisition response shows the shopper isn't known yet, you continue with a payment request that:

  • Refers to the card acquisition request.
  • Creates shopper identifiers to save in your back end system.

  1. Collect details from the shopper (depending on your use case), and ask the shopper's consent to save their details.
    You can let your staff enter the information in your POS app, but you can also make input requests to collect the information on the terminal. For example:

  2. Make a PaymentRequest with:

    Parameter Required Description
    SaleData.TokenRequestedType Customer. Returns the card alias in the TokenValue field of the response. Note that the card alias is always returned in the AdditionalResponse.
    PaymentData.CardAcquisitionReference -white_check_mark- An object referencing the card acquisition:
    • TimeStamp: The time stamp returned in the POIData.POITransactionID of the card acquisition response.
    • TransactionID: The transaction ID returned in the POIData.POITransactionID of the card acquisition response.
    SaleData.SaleToAcquirerData Data to create shopper identifiers.

    See the instructions below.

    In SaleData.SaleToAcquirerData include:

    • shopperReference: your unique reference for this shopper. Minimum length: three characters. Note that the value is case-sensitive. Do not include personally identifiable information (PII), such as name or email address.
    • shopperEmail: optional. The shopper's email address, if you collected that in the first step.
    • recurringContract: ONECLICK. This triggers us to store the shopper reference and email on our platform.

    Pass the SaleToAcquirerData value in one of the following formats:

    • Option 1: a JSON object converted to a Base64 encoded string. Refer to Add information to a payment.
    • Option 2: form-encoded key-value pairs (using & as a separator). For example:
      shopperReference=12345&shopperEmail=S.Hopper@example.com&recurringContract=ONECLICK

    The format that you use here, will also be the format of the AdditionalResponse that you receive.

  3. When you receive the response, keep the following identifiers from the AdditionalResponse (you may need to Base64-decode the string first):

    • alias: the card alias.
      If you specified a TokenRequestedType of Customer in the request, the card alias is also returned in PaymentToken.TokenValue.
    • PaymentAccountReference: a value that represents the shopper's payment account that their card and/or NFC wallet is linked to. For NFC wallet transactions, a PAN is not available and thus there's no card alias.
    • shopperReference: your unique reference for this shopper that you specified in the request.
    • shopperEmail: the shopper's email address that you specified in the request.

    The identifiers for this shopper are now stored on the Adyen payments platform.

  4. In your system, create a customer profile for the shopper and save the shopper identifiers that you received in the payment response.

  5. Also save the transaction data with the shopper's customer profile, to start building a transaction history.

Make a payment for a recognized shopper

When the card acquisition response shows the shopper is known already, you follow up with a payment request that refers to the card acquisition.

  1. Using the shopperReference or other identifiers you received in the card acquisition response, find the shopper in your system.

  2. Depending on your business logic, you may want to apply a discount, or offer a gift. For example:

  3. If necessary, update the final transaction amount. For example, if you applied a discount.

  4. Make a PaymentRequest with:

    Parameter Required Description
    SaleData.TokenRequestedType Customer. Returns the card alias in the TokenValue field of the response. Note that the card alias is always returned in the AdditionalResponse.
    PaymentTransaction.AmountsReq -white_check_mark- An object with:
    • Currency: The transaction currency.
    • RequestedAmount: The final transaction amount.
    PaymentData.CardAcquisitionReference -white_check_mark- An object containing data from the card acquisition:
    • TimeStamp: The time stamp returned in the POIData.POITransactionID of the card acquisition response.
    • TransactionID: The transaction ID returned in the POIData.POITransactionID of the card acquisition response.

  5. When you receive the response, keep the following identifiers from the AdditionalResponse (you may need to Base64-decode the string first):

    • alias: the card alias.
      If you specified a TokenRequestedType of Customer in the request, the card alias is also returned in PaymentToken.TokenValue.
    • PaymentAccountReference: a value that represents the shopper's payment account that their card and/or NFC wallet is linked to.
    • shopperReference: your unique reference for this shopper, if you specified that when you created the customer profile.
    • shopperEmail: the shopper's email address, if you specified that when you created the customer profile.

  6. In your system, store the transaction data with the shopper's customer profile.

Asynchronous flow

The asynchronous flow is a simpler implementation of shopper loyalty, where you rely on webhooks to make loyalty adjustments in your system after the payment. In this flow, you cannot apply discounts or other loyalty benefits on the spot before the payment.

  1. Make sure that you have set up receiving standard webhooks.
  2. Create a customer profile for the shopper in your loyalty system.
  3. Make a payment.
  4. Wait for the AUTHORISATION webhook.
  5. Based on the identifiers in the AUTHORISATION webhook, update the shopper's customer profile in your loyalty system. For example, add loyalty points.
  6. Inform the shopper of the update in your loyalty system.

For more information about this flow, see our omnichannel documentation.

See also