Difference between revisions of "Token payment upgrade to 3DS"

From Barion Documentation
Jump to navigation Jump to search
Line 1: Line 1:
 
{{PageTitle|title=Upgrading token payment implementation to use 3DS}}
 
{{PageTitle|title=Upgrading token payment implementation to use 3DS}}
 +
{{IncompletePage}}
 
{{NotificationBox|title=NOTE|text=This tutorial was created to help merchants that already have token payment integration with Barion. If you are planning to create a new integration, please read [[Token_payment_3D_Secure|this description]]!|color=#1993c7}}
 
{{NotificationBox|title=NOTE|text=This tutorial was created to help merchants that already have token payment integration with Barion. If you are planning to create a new integration, please read [[Token_payment_3D_Secure|this description]]!|color=#1993c7}}
  
Line 7: Line 8:
 
# Refer to this token in a subsequent payment attempt
 
# Refer to this token in a subsequent payment attempt
  
This meant that as far as this token referred to a valid and still available funding source the merchant could create payments without any limitations. Basically, this token symbolized the funding source. It was up to the merchant to decide what it is used for. To make sure that the payer has more control over these scenarios the 3DS authentication requires another identifier. This new identifier is used the differentiate these payment scenarios.
+
This meant that as far as this token referred to a valid and still available funding source the merchant could create payments without any limitations. Basically, this token symbolized the funding source. It was up to the merchant to decide what it is used for, neither Barion neither the card issuer was not aware of the nature of the subsequent payments.
 +
 
 +
[[File:Recurring-pre3ds.png|1200px]]
 +
 
 +
To make sure that the payer has more control over these scenarios there several things that change:
 +
* Merchant has to specify the nature of the transaction. This means that from now on the merchant has to categorize the transaction. It is not allowed to
 +
* merchant has to maintain a new identifier for every new category of
 +
 
 +
 
 +
 
 +
 
 +
3DS authentication requires another identifier. This new identifier is used to differentiate these payment scenarios. From now on there will be two IDs for every payer-not-present scenario:
 +
* <code>RecurrenceId</code> for the funding source: this identifies the source of the money (could be card or wallet)
 +
* <code>TraceId</code> (new) for the ''nature of the charge:'' this identifies the type of transaction the merchant is conducting.
 +
 
 +
 
 +
 
 +
 
  
 
{{NotificationBox|title=IMPORTANT|text=Starting from January 1 the [[3DSecure|3DS authentication]] will be mandatory for all of our partners!|color=#FF7A3D}}
 
{{NotificationBox|title=IMPORTANT|text=Starting from January 1 the [[3DSecure|3DS authentication]] will be mandatory for all of our partners!|color=#FF7A3D}}

Revision as of 11:23, 17 November 2020

Upgrading token payment implementation to use 3DS

WARNING
This article is incomplete. It may change significantly without any notice, so don't rely on any content you find here yet. Please check back later.
NOTE
This tutorial was created to help merchants that already have token payment integration with Barion. If you are planning to create a new integration, please read this description!

Token payment is a solution that enables the merchant to charge the payer without requiring the presence of the payer. It is a powerful tool to conduct subscription-like or payer-not-present scenarios. This scenario required the merchant to create a token that would act as an identifier for the payer's funding source (may it be a credit card or a Barion e-money account). To acquire such a token the merchant had to do several things:

  1. Create an alphanumeric token
  2. Register this token in the Barion system by attaching it to an initial payment and having the payer fulfill that payment (either by card or form an e-money account)
  3. Refer to this token in a subsequent payment attempt

This meant that as far as this token referred to a valid and still available funding source the merchant could create payments without any limitations. Basically, this token symbolized the funding source. It was up to the merchant to decide what it is used for, neither Barion neither the card issuer was not aware of the nature of the subsequent payments.

Recurring-pre3ds.png

To make sure that the payer has more control over these scenarios there several things that change:

  • Merchant has to specify the nature of the transaction. This means that from now on the merchant has to categorize the transaction. It is not allowed to
  • merchant has to maintain a new identifier for every new category of



3DS authentication requires another identifier. This new identifier is used to differentiate these payment scenarios. From now on there will be two IDs for every payer-not-present scenario:

  • RecurrenceId for the funding source: this identifies the source of the money (could be card or wallet)
  • TraceId (new) for the nature of the charge: this identifies the type of transaction the merchant is conducting.



IMPORTANT
Starting from January 1 the 3DS authentication will be mandatory for all of our partners!