Token payment upgrade to 3DS: Difference between revisions

From Barion Documentation
Jump to navigation Jump to search
VisualWikitext
m (replaced reference to v2 GetPaymentState with v4 PaymentState)
 
(19 intermediate revisions by 6 users not shown)
Line 1: Line 1:
{{PageTitle|title=Upgrading token payment implementation to comply with 3DS}}
{{PageTitle|title=Upgrading token payment implementation to comply with 3DS}}
__NOTOC__


{{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. First, please read through the detailed description of the new [[Token_payment_3D_Secure|token payment with 3DS]]!|color=#1993c7}}
 
__TOC__
 
= 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. To attach that token to a valid funding source the merchant had to do several things:
[[Token_payment_3D_Secure|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 22: Line 24:
First of all the merchant has to decide what kind of token payment scenario is suitable. These scenarios are the following:
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.
* '''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.
* '''Recurring payment''': The payer authorizes the merchant (at the initial payment) to charge their card periodically without being present with the same amount.
* '''Merchant initiated payment''': The payer authorizes the merchant to charge their card without restrictions.
* '''Merchant initiated payment''': The payer authorizes the merchant to charge their card without restrictions (eg. amounts can vary).
 
These scenarios have different properties and requirements, this table below summarizes the key differences.
 
{|class="wikitable"
|-
! Scenario
! Payer present?
! Amount
! Frequency
! Liability
|-
| One-click payment || Yes || Various || Various || Card issuer
|-
| Recurring payment || No || Fixed  || Various || Card issuer
|-
| Merchant initiated payment || No || Various  || Various || Merchant
|-
|}
 
<div style="border: 1px solid #aaa; background-color:#eee; font-size: 0.8em; padding:5px 10px;">
Explanation:<br/>
<hr/>
'''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. <br/>
'''Amount''': specifies whether the amount of the payments can change from payment to payment or must be the same.<br/>
'''Frequency''': specifies whether it is mandatory to wait a fixed number of days between payments or the charges can happen ad-hoc.  <br/>
'''Liability''': describes the entity who is liable for the payment in case of fraud
</div>
 
The '''Recurring Payment''' scenario has some extra restrictions. The merchant has to specify two additional properties in the [[Payment-Start-v2|Payment/Start]] request:
* <code>RecurringExpiry</code>: The date after the subsequent charges should not accepted.
* <code>RecurringFrequency</code>: The minimum days the merchant has to wait between payments.
 
Both properties are located in the [[PurchaseInformation]] property and must be specified if this scenario is selected.


To decide on a suitable scenario, please [[Token_payment_3D_Secure#Token_payment_scenarios|read this detailed description]]


To help you decide on a suitable scenario, please use the decision graph below:
{{NotificationBox|title=CHANGE|text=The intended scenario must be specified in the new [[RecurrenceType|RecurrenceType]] property (located in the [[Payment-Start-v2|Payment/Start]] request)|color=#20c400}}
 
[[File:3ds-recurrencetype-decision.jpg|500px]]
 
 
{{NotificationBox|title=CHANGE|text=The intended scenario must be specified in the new [[RecurrenceType|ReccurenceType]] property (located in the [[Payment-Start-v2|Payment/Start]] request)|color=#20c400}}


== Usage of TraceId ==
== Usage of TraceId ==
Line 74: Line 39:
* <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 and stored by the card issuer. 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-PaymentState-v4|/v4/Payment/<PaymentId>/PaymentState]] 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}}
{{NotificationBox|title=CHANGE|text=The TraceId must processed from the [[Payment-PaymentState-v4|PaymentState]] 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 crucial for the card transactions otherwise they could be declined. A <code>TraceId</code> can only be used again if:
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 crucial for the card transactions otherwise they could be declined.  
* the funding source is the same (technically the <code>RecurrenceId</code> is the same)
* the token payment scenario is the same (technically the <code>RecurrenceType</code> is the same)
* the request complies with the scenario restrictions


{{NotificationBox|title=CHANGE|text=The TraceId must specified in the [[Payment-Start-v2|Payment/Start]] for the subsequent token charges. |color=#20c400}}
{{NotificationBox|title=CHANGE|text=The TraceId must specified in the [[Payment-Start-v2|Payment/Start]] for the subsequent token charges. |color=#20c400}}
If any of these parameters change the merchant has to request new IDs. What to request depends on what needs to change. This is described in the [[Token_payment_upgrade_to_3DS#Changing the existing token IDs|Changing the existing token IDs]] section.
Since the <code>RecurrenceId</code> identifies the funding source it is possible that with the same <code>RecurrenceId</code> the merchant uses several different <code>TraceId</code> tokens. This is required in a scenario when the merchant wants to provide a new type of token payment for the payer but does not wants to redirect them to Barion again. This is described in the  [[Token_payment_upgrade_to_3DS#Multiple Trace IDs|Multiple Trace IDs]] section.


== 3DS v2 authentication ==
== 3DS v2 authentication ==
Line 93: Line 51:
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 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.  
The initial payment must be authenticated every time although the subsequent payments may be exempted in certain cases.  
* For '''One-click scenarios''' the payer is always present so for every purchase the payer must be authenticated via 3DS v2 (this does not mean that they will be challenged every time)
* For '''Recurring scenarios''' the initial payment must be authenticated and as long as the <code>TraceId</code> remains the same the subsequent payments are exempted from authentication.
* For '''Merchant initiated scenarios''' the initial payment must be authenticated and as long as the <code>TraceId</code> remains the same the subsequent payments are exempted from authentication.
This table summarizes the 3DS authentication requirements for different token scenarios.
{|class="wikitable"
|-
! Scenario
! Initial payment
! Subsequent payments
|-
| One-click payment || ✔️ || ✔️
|-
| Recurring payment || ✔️ ||
|-
| Merchant initiated payment || ✔️ ||
|-
|}




Line 122: Line 61:
#* <code>"RecurrenceType" : "RecurringPayment"</code> to indicate the scenario
#* <code>"RecurrenceType" : "RecurringPayment"</code> to indicate the scenario
#* <code>PurchaseInformation.RecurringExpiry</code> and <code>PurchaseInformation.RecurringFrequency</code> for the limitations <br/><br/>  
#* <code>PurchaseInformation.RecurringExpiry</code> and <code>PurchaseInformation.RecurringFrequency</code> for the limitations <br/><br/>  
#Once the callback is received get the response of [[Payment-GetPaymentState-v2|GetPaymentState]]. In case the charge was successful, there will be a <code>TraceId</code> property for the payment. The value of it must be saved and attached to the payment.   
#Once the callback is received get the response of [[Payment-PaymentState-v4|PaymentState]]. In case the charge was successful, there will be a <code>TraceId</code> property for the payment. The value of it must be saved and attached to the payment.   
#'''For subsequent payments''' in the [[Payment-Start-v2|Payment/Start]] request specify the  
#'''For subsequent payments''' in the [[Payment-Start-v2|Payment/Start]] request specify the  
#* <code>"RecurrenceType" : "RecurringPayment"</code>
#* <code>"RecurrenceType" : "RecurringPayment"</code>
Line 131: Line 70:
#''' For the token registration''' in the [[Payment-Start-v2|Payment/Start]] request the new property has to be specified:
#''' For the token registration''' in the [[Payment-Start-v2|Payment/Start]] request the new property has to be specified:
#* <code>"RecurrenceType" : "MerchantInitiatedPayment"</code> to indicate the scenario
#* <code>"RecurrenceType" : "MerchantInitiatedPayment"</code> to indicate the scenario
#Once the callback is received get the response of [[Payment-GetPaymentState-v2|GetPaymentState]]. In case the charge was successful, there will be a <code>TraceId</code> property for the payment. The value of it must be saved and attached to the payment.   
#Once the callback is received get the response of [[Payment-PaymentState-v4|PaymentState]]. In case the charge was successful, there will be a <code>TraceId</code> property for the payment. The value of it must be saved and attached to the payment.   
#'''For subsequent payments''' in the [[Payment-Start-v2|Payment/Start]] request specify the  
#'''For subsequent payments''' in the [[Payment-Start-v2|Payment/Start]] request specify the  
#* <code>"RecurrenceType" : "MerchantInitiatedPayment"</code>
#* <code>"RecurrenceType" : "MerchantInitiatedPayment"</code>
Line 142: Line 81:
#''' For the token registration''' in the [[Payment-Start-v2|Payment/Start]] request the new property has to be specified:
#''' For the token registration''' in the [[Payment-Start-v2|Payment/Start]] request the new property has to be specified:
#* <code>"RecurrenceType" : "OneClickPayment"</code> to indicate the scenario
#* <code>"RecurrenceType" : "OneClickPayment"</code> to indicate the scenario
#'''For subsequent payments''' the merchant has to integrate the barion.offsite.js to be able to authenticate the payer via 3DS v2 on the merchant's site. To do this read the tutorial on [[Token_payment_3D_Secure#OneClick payment|how to integrate this]].
#'''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 [[Token_payment_3D_Secure#OneClick payment|how to integrate this]].
# After a successful authentication a new Barion API endpoint ([[Payment-Complete-v2|/Payment/Complete]]) must be called to finalize the process and charge the card
# After a successful authentication a new Barion API endpoint ([[Payment-Complete-v2|/Payment/Complete]]) must be called to finalize the process and charge the card


Line 148: Line 87:


{{NotificationBox|title=CHANGE|text=In case of one-click token scenario the merchant has to authenticate every card payment with 3DS v2|color=#20c400}}
{{NotificationBox|title=CHANGE|text=In case of one-click token scenario the merchant has to authenticate every card payment with 3DS v2|color=#20c400}}
= Changing the existing token IDs =
Sometimes it is important to re-register already existing token IDs. Let's go over these possible scenarios
==Changing the funding source==
This could happen if the funding source becomes invalid for some reason (card gets deleted or expires) or the merchant decides to use that token for another payer. In this case, the merchant has to register the <code>RecurrenceId</code> again.
To do this a new payment must be started and in the [[Payment-Start-v2|Payment/Start]] request the following setup should be specified:
* the <code>InitiateRecurrence</code> field has to be set to <code>true</code>
* the <code>RecurrenceId</code> has to be specified.
* and the <code>TraceId</code> should not be specified.
Since the <code>TraceId</code> is bound to the payer and the process if the funding source changes new <code>TraceId</code> will be generated. This new ID must be saved to this payment and must be used from this moment on for subsequent payments.
==Changing the token payment scenario==
This could occur when the merchant wants to get authorization from the payer to a new token scenario for the already registered funding source. To be able to do this the merchant has to have a valid and registered <code>RecurrenceId</code>.
Let's see some examples when this may be necessary:
* The payer subscribed to the merchant's service beforehand and the merchant decided to use the recurring payment token scenario. The payer wants to subscribe to another service and this requires a different payment schedule. This means that the <code>RecurringFrequency</code> that was specified initially can not be maintained so it is required to acquire a new <code>TraceId</code>
* The payer bought something on the merchant's website and uses the one-click feature for subsequent fast non-redirect payments. After a while, the payer decides to subscribe to a service provided by this same merchant. This means that the merchant has to create a new token scenario (not a one-click payment but a recurring payment). For this, the merchant has to acquire a new <code>TraceId</code>. This can be done without redirecting the payer to Barion using the existing <code>RecurrenceId</code> and performing a 3DS authentication on the merchant's website.
To do these a new payment must be started and in the [[Payment-Start-v2|Payment/Start]] request the following setup should be specified:
* the <code>InitiateRecurrence</code> field has to be set to <code>false</code>
* the <code>RecurrenceId</code> has to be specified.
* and the <code>TraceId</code> should not be specified.
After this, a 3DS authentication has to be completed to acquire a new trace ID. This can be done on the merchant's site if the merchant implements the barion.offsite.js for off-site 3DS authentication.
This means that it can be achieved to acquire different Trace IDs for different scenarios with only one RecurrenceId.
This is basically categorizing the different token scenarios as opposed to using every subsequent payment as an unmarked charge.
[[File:Recurring-post3ds.png|1280px]]
== What happens if the merchant doesn't upgrade its implementation ==
There is a transition period for the integrators to upgrade their system. In this period both of these integrations will work. Once the period is not the initial payments nor the subsequent payments will succeed.
{{NotificationBox|title=SUPPORT|text=In case you have difficulties with the upgrade please contact our developers at [email protected] |color=#1993c7}}

Latest revision as of 10:33, 25 March 2024

Upgrading token payment implementation to comply with 3DS

NOTE
This tutorial was created to help merchants that already have token payment integration with Barion. First, please read through the detailed description of the new token payment 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:

  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 with the same amount.
  • Merchant initiated payment: The payer authorizes the merchant to charge their card without restrictions (eg. amounts can vary).

To decide on a suitable scenario, please read this detailed description

CHANGE
The intended scenario must be specified in the new RecurrenceType 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 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 /v4/Payment/<PaymentId>/PaymentState response once the charge is successfully completed.

CHANGE
The TraceId must processed from the PaymentState 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 crucial for the card transactions otherwise they could be declined.

CHANGE
The TraceId must specified in the Payment/Start for the subsequent token charges.

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

  1. For the token registration in the Payment/Start request the new properties have to be specified:
    • "RecurrenceType" : "RecurringPayment" to indicate the scenario
    • PurchaseInformation.RecurringExpiry and PurchaseInformation.RecurringFrequency for the limitations

  2. Once the callback is received get the response of PaymentState. 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.
  3. 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

  1. For the token registration in the Payment/Start request the new property has to be specified:
    • "RecurrenceType" : "MerchantInitiatedPayment" to indicate the scenario
  2. Once the callback is received get the response of PaymentState. 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.
  3. 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.

  1. For the token registration in the Payment/Start request the new property has to be specified:
    • "RecurrenceType" : "OneClickPayment" to indicate the scenario
  2. 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.
  3. 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.

CHANGE
In case of one-click token scenario the merchant has to authenticate every card payment with 3DS v2
Retrieved from "https://docs.barion.com/index.php?title=Token_payment_upgrade_to_3DS&oldid=4304"