Token payment 3D Secure
Token Payment 3D Secure
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 :
- OneClick payment: the user is charged upon her request initiated on the website of the merchant. This type of payment is subject to 3DS, the appropriate solutions should be implemented on the merchant's side (see below).
- when the merchant initiates the payment without the user being present:
- Recurring payment: the user is charged with the same amount on a regular basis. This type of payment is subject to 3DS, with exemption (meaning that challenge flow won't/can't be presented, but as much available data should be sent as possible)
- MIT (merchant initiated transaction): the user is charged on an irregular basis and/or with diffreent amount. This type of payment is not subject to 3DS.
To be able to integrate your webshop with the Barion Payment Gateway:
- For this wallet you have to create a shop which should be approved by Barion.
- To make sure every corner case scenario works for your webshop it is best to topup that account with a small amount (approx. 5-10EUR or your choice of currency around the same value).
- For the technical communication guide please read this: Calling the API
The payment process
The process is divided into two major steps:
- 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.
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, customer, funding source combination.
Example JSON request
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
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
Displaying the funding source in a GUI
Possible error responses
Using the token
To be able to use a token, the original payment must be in a successful state. Depending on the type of the payment, 3DS might be required. 3DS is not required in the following cases:
- the token was requested before 3DS came into effect
- the original payment was not initialized by bank card
Step 1 : Initialize oneClick
Step 2 : Make a payment
InitiateRecurrence should be set to
false and the appropriate Recurrence Type should be sent. 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 along with the
Example Payment/Start json request
Processing the Payment/Start response
|PaymentId||Payment Identifier of the purchase in Barion|
|ThreeDSAuthClientData||basae64 encoded 3DS client data|
Example Payment/Start response
Step 3: 3DS authentication & challenge
This data then should be passed onto the
BarionThreeDSecure.startProcess method, which will do all the magic to authenticate and display the challenge (if needed).
When the request is finished the appropriate callback is fired, the BarionClient was initialized with in Step 1. In case of successful authentication, you have to call our /Payment/CompletePayment endpoint, where the actual charge will happen.
Possible error responses
|InvalidRecurrenceId||The token specified in the |