Token payment upgrade to 3DS: Difference between revisions
Line 102: | Line 102: | ||
In this period the integrations that are not up-to-date and are not capable to handle 3DS v2 transactions '''will work'''. However, to comply with the card scheme mandates Barion has to substitute the missing information. | In this period the integrations that are not up-to-date and are not capable to handle 3DS v2 transactions '''will work'''. However, to comply with the card scheme mandates Barion has to substitute the missing information. | ||
* New tokens can be initiated (without 3DSv2 information) and the 3DSv2 authentication will be performed by the Barion Smart Gateway. The payment will be marked as an initial MIT transaction. The MerchantInitiatedPayment RecurrenceType will be used as a fallback. | * New tokens can be initiated (without 3DSv2 information) and the 3DSv2 authentication will be performed by the Barion Smart Gateway. The payment will be marked as an initial MIT transaction. The MerchantInitiatedPayment RecurrenceType will be used as a fallback. | ||
* Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId. They will be handled as the subsequent MIT payment of the initial transaction. The TraceId | * Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId. They will be handled as the subsequent MIT payment of the initial transaction. The TraceId will be filled in by Barion. | ||
Line 109: | Line 109: | ||
Until this date, all integrations must be upgraded. | Until this date, all integrations must be upgraded. | ||
* New tokens can only be initiated with the appropriate 3DSv2 information (RecurrenceType set). Otherwise, the payment/start will result in a validation error. | * New tokens can only be initiated with the appropriate 3DSv2 information (RecurrenceType set). Otherwise, the payment/start will result in a validation error. | ||
* Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId. They will be handled as the subsequent MIT payment of the initial transaction. The TraceId | * Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId. They will be handled as the subsequent MIT payment of the initial transaction. The TraceId will be filled in by Barion. This can be used until the card schemes allow this kind of TraceId substitution. | ||
{{NotificationBox|title=SUPPORT|text=In case you have difficulties with the upgrade please contact our developers at [email protected] |color=#1993c7}} | {{NotificationBox|title=SUPPORT|text=In case you have difficulties with the upgrade please contact our developers at [email protected] |color=#1993c7}} |
Revision as of 13:41, 10 December 2020
Upgrading token payment implementation to comply with 3DS
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:
- Create an alphanumeric token
- Conduct an initial payment in which this token gets registered in the Barion system
- 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.
To decide on a suitable scenario, please read this detailed description
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 a non-fraudulent 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.
Once the TraceId
is acquired it must be sent in the Payment/Start request to identify the scenario. This is crucial for the card transactions otherwise they could be declined.
3DS v2 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.
Technical changes required
The technical changes depend on what type of token scenario is needed for the business. It is important to notice that these scenarios can be implemented beside each other, a merchant is not required to choose only one type of token payment. The main goal is to appropriately use each scenario.
Technical changes for Recurring payments
- For the token registration in the Payment/Start request the new properties have to be specified:
"RecurrenceType" : "RecurringPayment"
to indicate the scenarioPurchaseInformation.RecurringExpiry
andPurchaseInformation.RecurringFrequency
for the limitations
- Once the callback is received get the response of GetPaymentState. In case the charge was successful, there will be a
TraceId
property for the payment. The value of it must be saved and attached to the payment. - For subsequent payments in the Payment/Start request specify the
"RecurrenceType" : "RecurringPayment"
- and the
TraceId
you received for the initial payment.
Technical changes for Merchant initiated payments
- For the token registration in the Payment/Start request the new property has to be specified:
"RecurrenceType" : "MerchantInitiatedPayment"
to indicate the scenario
- Once the callback is received get the response of GetPaymentState. In case the charge was successful, there will be a
TraceId
property for the payment. The value of it must be saved and attached to the payment. - For subsequent payments in the Payment/Start request specify the
"RecurrenceType" : "MerchantInitiatedPayment"
- and the
TraceId
you received for the initial payment.
Technical changes for One-click payments
This modification needs the most attention since the merchant has to implement client-side functionality and add a new step at the end of the flow.
- For the token registration in the Payment/Start request the new property has to be specified:
"RecurrenceType" : "OneClickPayment"
to indicate the scenario
- For subsequent payments the merchant has to integrate the barion.offsitegw.js to be able to authenticate the payer via 3DS v2 on the merchant's site. To do this read the tutorial on how to integrate this.
- After a successful authentication a new Barion API endpoint (/Payment/Complete) must be called to finalize the process and charge the card
Please notice that in case this scenario is used there is no need to use the TraceId
since the 3DS authentication will be performed every time.
What happens if the merchant doesn't upgrade its implementation
There will be a two-phase ramp-up period to make sure that integrations can be upgraded.
Until December 31, 2020
In this period the integrations that are not up-to-date and are not capable to handle 3DS v2 transactions will work.
- New tokens can be initiated (without 3DSv2 information) and the 3DSv2 authentication will be performed by the Barion Smart Gateway.
- Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId.
Between January 1 and January 31, 2021
In this period the integrations that are not up-to-date and are not capable to handle 3DS v2 transactions will work. However, to comply with the card scheme mandates Barion has to substitute the missing information.
- New tokens can be initiated (without 3DSv2 information) and the 3DSv2 authentication will be performed by the Barion Smart Gateway. The payment will be marked as an initial MIT transaction. The MerchantInitiatedPayment RecurrenceType will be used as a fallback.
- Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId. They will be handled as the subsequent MIT payment of the initial transaction. The TraceId will be filled in by Barion.
From February 1, 2021
Until this date, all integrations must be upgraded.
- New tokens can only be initiated with the appropriate 3DSv2 information (RecurrenceType set). Otherwise, the payment/start will result in a validation error.
- Subsequent payments can use existing tokens (RecurrenceId) without specifying the TraceId. They will be handled as the subsequent MIT payment of the initial transaction. The TraceId will be filled in by Barion. This can be used until the card schemes allow this kind of TraceId substitution.