Token payment

Token Payment

This payment scenario allows the integrator shop to register a customer (and a funding source) in the Barion system and then later on charge the customer without redirecting her to the Barion Payment Gateway UI. This means that the customer authorizes the shop to charge her card or Barion balance without typing in the card information or Barion login again.

Token payment can be used in two use cases:

• when the user is present on the website of the merchant and she decides to pay (customer iniitated payment/transaction - e.g. one-click payment, recurring payment)
• when the merchant initiates the payment without the user being present (merchant initiated payment/transaction)

Premium feature

This scenario is not allowed automatically for every approved shop and should be requested from Barion!

Prerequisites

To be able to integrate your webshop with the Barion Payment Gateway:

• You must register a Barion wallet at the Barion website or in the Sandbox environment. Learn more about the Sandbox environment here.
• For this wallet you have to create a shop which should be approved by Barion.
• For every currency you plan to conduct payments in you have to make sure there is an account created in your Barion wallet. This means that if you plan to have USD payments then there should be an USD account created in your wallet.
• To make sure every corner case scenario works for your webshop it is best to topup that account with a small amount (aprrox. 5-10EUR or your choice of currency around the same value).
• For the technical communication guide please read the this: Calling the API

The payment process

The process is divided into two major steps:

1. Creating the token that represents one of the customer's funding sources (credit card or e-money wallet)
2. Using the registered token to charge the customer

Creating the token

To be able to use a token payment scenario first we have to register the token with Barion. The token registration is basically a normal payment with two new properties in the Payment/Start request. This means that we have to make sure that the customer is well aware of the fact that they are giving consent to a tokenized payment. The Barion payment does not indicate in any way that the payment is a token payment.

The token is registered to the shop and not to the wallet. So if the Barion wallet has multiple shops registered the token can not be shared among them even if the customer is the same.

One of the properties is the InitiateRecurrence property. This is a bool property, if you set it to true then the payment gateway will consider the request as a token registration. This happens even if the customer is already has a registered token, so you are able to re-register a customer.

The other required property for a token registration is the token itself. This is generated by the shop and has to be unique for every registration. The token should be specified in the RecurrenceId property of the Payment/Start request. This token should be stored in the webshop database. Make sure that multiple tokens can belong to a single customer because the token is only unique for a specific shop/shop union, customer, funding source combination.

An already used RecurrenceId can be used for re-registration, in this case the new funding source will be registered for the token.

Shop Union

Multiple shops (not necessarily belonging to the same account) can use the same RecurrenceId. In this case the shops form a so-called union, and all shops belonging to that specific union can use the same RecurrenceId.
So for eg.

• [email protected] has ShopA and ShopB
• [email protected] has ShopC

If these shops belong to the same union, a token initialized by ShopA can be used in both ShopB and ShopC. Likewise a token initialized by ShopC can be used in ShopA and ShopB.

This feature is controlled by Barion Administrators, should you be interested, drop us a line at [email protected] with your Barion account email(s) and Shop names.

Shop Union Restrictions

• Any number of shops from any account can join a Union
• A shop can only belong to one union
• Any shop that is not a member of a Union cannot use or create a Union token
• A shop that was previously a member of the Union but is already a member of another union cannot use its previously available Union tokens
• Any shop that is a member of the Union can use payment tokens initialized by all members of the union, even retroactively
• Every store that is a member of a Union can only create tokens that belong to its own Union (so you can't initialize tokens that are independent of the Union or belong to another Union)
• If a Union has been deleted, the associated tokens cannot be used

Example JSON request

{
    "POSKey": "E31EC263-01DC-40BD-BDF1-38FC7A332434",
    "PaymentType": "Immediate",
    "PaymentRequestId": "EXMPLSHOP-PM-001",
    "InitiateRecurrence": true,
    "RecurrenceId": "SHOP-XMLP-TOKEN-ABC-123",
    "FundingSources": ["All"],
    "Currency": "EUR",
    "Transactions": [
        {
            "POSTransactionId": "EXMPLSHOP-PM-001/TR001",
            "Payee": "[email protected]",
            "Total": 25.2,
            "Comment": "Subsription fee for the first month",
            "Items": [
                {
                    "Name": "Website subscription",
                    "Description": "Website subscription for one month",
                    "Quantity": 1,
                    "Unit": "month",
                    "UnitPrice": 25.2,
                    "ItemTotal": 25.2,
                    "SKU": "EXMPLSHOP/SKU/PHC-01"
                }
            ]
        }
    ]
}

Customer selects funding source

After the proper payment preparation the customer is redirected to the secure Barion gateway to choose between funding sources. The funding source the customer selects will be registered to the token. The funding source can either be an e-money wallet or a bank card. This means that even though the customer may own multiple cards only the one that was registered to the token can be used for future token payments. To change the funding source attached to the token a new registration should be requested.

Processing the response

The response is almost the same as to a basic Immediate scenario. The only difference is that there is the RecurrenceResult property that tells the result of the token registration. This could be either

• Successful: the token is registered and live, can be used for payment
• Failed: the token registration was not successful, the token can not be used
• None: this could only happen if no token payment was requested
• NotFound: this could only happen if the given identifier is invalid

Displaying the funding source in a GUI

We strongly advise to save the complete response for future reference. The FundingSource field tells if the funding source is a Barion balance or a card. If it is a card, it is useful to save FundingInformation for displaying it for the user, when requesting future payments. The usual way to display funding sources is to show the last 4 digits of the card, with the rest represented by stars, eg: **** **** **** 1234. The card used can be obtained from FundingInformation's BankCard field. The CardType field can be used to display the appropriate card logo. You can even show, if the card is expired, and offer to register another one.

Possible error responses

Error code	Description
RecurringPaymentNotAllowed	The token payment is not allowed for the shop identified by the POSKey. Contact Barion to request this feature.

Using the token

You can use the token for one-click payment in a shop (like on Amazon or in Uber) or to automatically charge the user (e.g. in case of a subscription). To use an already registered token for a payment, you have to use the same /Payment/Start API endpoint but the InitiateRecurrence should be set to false. This tells the Barion API to use the token for payment instead of only registering it. The token should be specified in the RecurrenceId property.

There is no amount limitation for the token payment and the payment scenarios could be changed as well for the token charge. This means that the token payment can be reservation even if the original payment was an immediate scenario.

Processing the response

The structure of the response is the same as the normal /Payment/Start response just the statuses will be different. In this case

• the payment level Status will be Succeeded instead of Prepared
• the transaction level Status will be Succeeded instead of Prepared
• the RecurrenceResult will be Successful instead of None

Although this is an immediate response that indicates a successful charge the callback mechanism still will be in motion as well.

Possible error responses

Error code	Description
InvalidRecurrenceId	The token specified in the RecurrenceId is invalid. Check if the token registration was successful.
RecurringPaymentDenied	Something happened to the user since the token registration, either deleted, suspended or blocked. The payment s not allowed in these cases.
InsufficientFunds	If the original payment was with e-money wallet and the customer doesn't have enough money to fulfill this charge this error happens.
OriginalPaymentWasntSuccessful	This means that the token belongs to an originally unsuccessful payment so this token can not be used anymore. This could only happen if the original payment was financed with a credit card.
InvalidCurrency	If the original payment was paid with e-money and the current token payment is in a currency that the wallet does not have an account in this error happens.