API only with raw card data

Use our APIs to accept card payments with raw card data, and build your own UI to have full control over the look and feel of your checkout page.

Requirements

Build your payment form for cards

When making a card payment, collect the following shopper details:

Card details	Example input	Required
Card number	"4111111111111111"
Card expiry month	"03"
Card expiry year	"30"
Card security code (CVV / CVC)	"737"
Cardholder name	"S. Hopper"

Showing co-badged cards

For cards issued in some countries/regions, you must comply with regulations for co-badged cards.

Use the /cardDetails endpoint to identify the brands on the shopper's card. To identify the brands, start making /cardDetails requests while the shopper is entering the card number. You need a minimum of the first 8 digits, but the full card number gives the best result.

If the /cardDetails endpoint identifies two brands and you support both, you must let the shopper choose which brand to pay with. If you only support one brand, let the shopper pay with it.

1. Make a POST /cardDetails request including the following:

   Parameter	Description	Required
   merchantAccount	Your merchant account.
   cardNumber	A minimum of the first 8 digits of the card number and a maximum of the full card number.
   countryCode	The shopper's country. The country code of the terminal's location. Format: the two-letter ISO-3166-1 alpha-2 country code. Exception: QZ (Kosovo).
   supportedBrands	The array of the card brands that you support. This is the brands array from your /paymentMethods response. If not provided, we assume that you support all card brands.

2. The response has a brands array containing the brands on the card. If you included supportedBrands in the request, the response shows the ones you support.

   The following example shows a response where:

   • The brands on the card are visa and cartebancaire.
   • The merchant account only supports visa.

3. If you support both brands, you must let the shopper choose their preferred brand. Render brand logos and names in the payment form for the shopper to choose one and include the brand when making a payment.

Make a payment

From your server, make a /payments request, specifying:

Field	Description	Required
paymentMethod.type	scheme
paymentMethod.number	The card number (without separators).
paymentMethod.expiryMonth	The card expiry month.
paymentMethod.expiryYear	The card expiry year.
paymentMethod.cvc	The card verification code.
paymentMethod.holderName	The name of the cardholder.
paymentMethod.brand	If the card is co-badged, this is the brand that the shopper choose to pay with. This is the brands.type from the /cardDetails response that matches the shopper's preferred brand.
paymentMethod.threeDS2SdkVersion	The version of the 3D Secure 2 mobile SDK. Required for mobile integrations to trigger in-app Native 3D Secure 2 (iOS or Android.

The /payments response contains:

• pspReference: Our unique identifier for the transaction.
• resultCode: Use this to present the payment result to your shopper.
• merchantReference: The reference from the /payments request.
• additionalData: Additional information about the transaction.
  To specify the fields that you want to receive in additionalData, log in to your Customer Area, and go to Developers > Additional data.

Present the payment result

Use the  resultCode from the /payments response to present the payment result to your shopper. You will also receive the outcome of the payment asynchronously in a webhook.

For card payments, you can receive the following resultCode values:

Present debit and credit cards separately

In some scenarios, you may want to present your shoppers with separate payment forms for debit cards and credit cards. Some examples include:

• If you accept payments in Sweden, you need to present debit cards before credit cards in order to comply with local legislation.
• In Brazil, many shoppers use Combo cards, allowing for both debit and credit transactions. Having a separate form for Debit Card and Credit Card gives your shoppers a clear indication of whether they are making a debit or credit transaction.

For more details, see the corresponding sections about Brazil and Sweden.

To show debit and credit cards separately:

1. If you are using the /paymentMethods endpoint to get a list of payment methods to present on the client side, include:

   • splitCardFundingSources: Set this to true to receive separate objects for credit and debit cards in the response.
     
     

   The following example shows how to get the available payment methods for a shopper in the Netherlands, making a EUR 47.00 payment.

   The response includes the list of available payment methods, with debit and credit cards split into separate objects.

2. When the shopper selects to pay with either a debit or credit card, proceed to make a POST /payments request and include:

   • paymentMethod.fundingSource: Set this to either credit or debit.
     
     

   The following example shows how you can make a payment request for a debit card.

Brazil

For debit transactions, we highly recommend using 3D Secure and automatic capture due to some issuers' restrictions.

Sweden

When accepting payments in Sweden, present debit before credit cards, and label the forms clearly in order to comply with Swedish legislations.

Recurring payments

Cards support tokenization for one-click, subscription, and unscheduled card-on-file payments. Refer to Create tokens to integrate with our tokenization feature.

Store card details

When creating a token for cards:

• Use the standard tokenization parameters in your payment request. You do not need to include any additional parameters for cards.

Show stored cards

1. In your /paymentMethods request, include the shopperReference that you specified when creating the token to receive the stored payment details for the shopper.

   The /paymentMethods response includes a storedPaymentMethods array containing the stored payment methods for this shopper. The storedPaymentMethods array contains the id that you need when making a payment.

            {
            ...
            "storedPaymentMethods":[
                {
                   "brand":"visa",
                   "expiryMonth":"10",
                   "expiryYear":"2020",
                   "holderName":"John Smith",
                   "id":"8415718415172204",
                   "lastFour":"1111",
                   "name":"VISA",
                   "supportedShopperInteractions":[
                      "Ecommerce",
                      "ContAuth"
                   ],
                   "type":"scheme"
                }
            ]
            ...
            }

2. Collect the following card details from the shopper in your payment form:

   Card details	Example input
   The security code (CVV / CVC)	"737"

Make a one-click payment

Make a one-click payment using standard tokenization parameters. You do not need to include any additional parameters for cards.

Make a subscription payment

Make a subscription payment using standard tokenization parameters. You do not need to include any additional parameters for cards.

Make an unscheduled card-on-file payment

Make an unscheduled card-on-file payment using standard tokenization parameters. You do not need to include any additional parameters for cards.

Test and go live

Before making live card payments:

1. Test your integration using our test card numbers. You can check the status of test payments in your Customer Area > Transactions > Payments.

2. Add the cards that you want to accept in your live Customer Area.

3. Before you can start accepting card payments in the live environment, you need to assess your PCI DSS compliance and submit the required Self-Assessment Questionnaire D document. For more information, refer to PCI DSS compliance guide.

See also