Token payment upgrade to 3DS: Difference between revisions

From Barion Documentation
Jump to navigation Jump to search
No edit summary
No edit summary
Line 4: Line 4:
{{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}}
= Background =
= Background =
[[Token_payment|Token payment]] is a solution that enables the merchant to charge the payer without the presence of them. It is a powerful tool to conduct subscription-like or payer-not-present scenarios. This scenario requires 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 attach that token to a valid funding source the merchant had to do several things:
[[Token_payment|Token payment]] is a solution that enables the merchant to charge the payer without the presence of them. It is a powerful tool to conduct subscription-like or payer-not-present scenarios. This scenario requires the merchant to create a token that would act as an identifier for the payer's funding source. To attach that token to a valid funding source the merchant had to do several things:
# Create an alphanumeric token
# Create an alphanumeric token
# Conduct an initial payment in which this token gets registered in the Barion system  
# Conduct an initial payment in which this token gets registered in the Barion system  
Line 12: Line 12:


This meant that as far as this token referenced 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 nor the card issuer was aware of the nature of the subsequent payments.  
This meant that as far as this token referenced 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 nor the card issuer was aware of the nature of the subsequent payments.  
This funding source can be either a card or an e-money wallet and this is up to the payer to choose. In case the payer chooses to fund the payment from their e-money wallet there is no further need for extra security. On the other hand when it comes to card payment the authentication process changed with the new Strong Customer Authentication directive and the 3DS v2 protocol.


= Changes =
= Changes =
To make sure that the payer has more control over these scenarios and the card issuer knows more about the payment scenarios several things need to be provided.  
To make sure that the payer has more control over these token scenarios and the card issuer knows more about the payment scenarios several things need to be changed.  


== Token payment scenarios ==
== Token payment scenarios ==
Line 50: Line 52:
</div>
</div>


To help you decide on a suitable scenario, please use the decision chart graph below:
To help you decide on a suitable scenario, please use the decision graph below:


[[File:3ds-recurrencetype-decision.jpg|500px]]
[[File:3ds-recurrencetype-decision.jpg|500px]]
Line 58: Line 60:
== Usage of TraceId ==
== Usage of TraceId ==


3DS authentication requires another identifier. This new identifier is used to differentiate these token payment scenarios.  
3DS authentication requires another identifier. This new identifier is used to differentiate these token payment scenarios and help the issuer control what is non-fraudalent transaction.


From now on there will be two IDs for every payer-not-present scenario:
So 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>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 token payment scenario the merchant is conducting.
* <code>TraceId</code> (new) for the ''nature of the charge:'' this identifies the type of token payment scenario the merchant is conducting.


This new <code>TraceId</code> is generated by the card issuer and stored by Barion. The Id is available in the [[Payment-GetPaymentState-v2|GetPaymentState]] response once the charge is successfully completed.
This new <code>TraceId</code> is generated and stored by the card issuer. The Id is available in the [[Payment-GetPaymentState-v2|GetPaymentState]] response once the charge is successfully completed.
 
{{NotificationBox|title=CHANGE|text=The TraceId must processed from the [[Payment-GetPaymentState-v2|GetPaymentState]] response and must be attached to the payment in merchant's system. |color=#20c400}}


Once the <code>TraceId</code> is acquired it must be sent in the [[Payment-Start-v2|Payment/Start]] request to identify the scenario. This is crutial for the card transactions othherwise the





Revision as of 08:33, 19 November 2020

Upgrading token payment implementation to comply with 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!

Background

Token payment is a solution that enables the merchant to charge the payer without the presence of them. It is a powerful tool to conduct subscription-like or payer-not-present scenarios. This scenario requires the merchant to create a token that would act as an identifier for the payer's funding source. To attach that token to a valid funding source the merchant had to do several things:

  1. Create an alphanumeric token
  2. Conduct an initial payment in which this token gets registered in the Barion system
  3. Refer to this token in a subsequent payment attempt

This meant that as far as this token referenced 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 nor the card issuer was aware of the nature of the subsequent payments.

This funding source can be either a card or an e-money wallet and this is up to the payer to choose. In case the payer chooses to fund the payment from their e-money wallet there is no further need for extra security. On the other hand when it comes to card payment the authentication process changed with the new Strong Customer Authentication directive and the 3DS v2 protocol.

Changes

To make sure that the payer has more control over these token scenarios and the card issuer knows more about the payment scenarios several things need to be changed.

Token payment scenarios

First of all the merchant has to decide what kind of token payment scenario is suitable. These scenarios are the following:

  • One-click payment: The payer clicks on the "Purchase" button but the charge happens in the background without the payer leaving the merchant's site.
  • Recurring payment: The payer authorizes the merchant (at the initial payment) to charge their card periodically without being present.
  • Merchant initiated payment: The payer authorizes the merchant to charge their card without restrictions.

These scenarios have different properties and requirements, this table below summarizes the key differences.

Scenario Payer present? Amount Frequency Liability
One-click payment Yes Various Various Card issuer
Recurring payment No Various Fixed Card issuer
Merchant initiated payment No Various Various Merchant

Explanation:


Payer present: indicates whether the payer is present during the subsequent payments. During the first (initial) payment, the payer is always present in every scenario.
Amount: specifies whether the amount of the payments can change from payment to payment or must be the same.
Frequency: specifies whether it is mandatory to wait a fixed number of days between payments or the charges can happen ad-hoc.
Liability: describes the entity who is liable for the payment in case of fraud

To help you decide on a suitable scenario, please use the decision graph below:

File:3ds-recurrencetype-decision.jpg

CHANGE
The intended scenario must be specified in the new ReccurenceType property (located in the Payment/Start request)

Usage of TraceId

3DS authentication requires another identifier. This new identifier is used to differentiate these token payment scenarios and help the issuer control what is non-fraudalent transaction.

So 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 token payment scenario the merchant is conducting.

This new TraceId is generated and stored by the card issuer. The Id is available in the GetPaymentState response once the charge is successfully completed.

CHANGE
The TraceId must processed from the GetPaymentState response and must be attached to the payment in merchant's system.

Once the TraceId is acquired it must be sent in the Payment/Start request to identify the scenario. This is crutial for the card transactions othherwise the



CHANGE
The TraceId must processed from the GetPaymentState response and should be sent during the subsequent charges.


Prepare for 3DS authentication

The new more secure 3DS v2 authentication must be conducted for every online card payment. These token payment scenarios also need to use these new secure way of authentication. The initial payment must be authenticated every time although the subsequent payments may be exempted in certain cases. This table displays the different scenarios and the 3DS authentication requirements.

Scenario Initial payment Subsequent payments
One-click payment ✔️ ✔️
Recurring payment ✔️
Merchant initiated payment ✔️



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


What happens if I don't change my implementation

TODO