Token payment upgrade to 3DS: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
{{IncompletePage}} | {{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}} | ||
= Background = | = Background = | ||
[[Token_payment|Token payment]] is a solution that enables the merchant to charge the payer without | [[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: | ||
# Create an alphanumeric token | # 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 | # Refer to this token in a subsequent payment attempt | ||
[[File:Recurring-pre3ds.png|1280px]] | |||
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. | |||
= 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 | 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. | ||
== Token payment scenarios == | == Token payment scenarios == | ||
First of all the merchant has to decide what kind of token payment scenario is | |||
* '''One-click payment''': The payer clicks on the "Purchase" button but | First of all the merchant has to decide what kind of token payment scenario is suitable. These scenarios are the following: | ||
* '''Recurring payment''': The payer authorizes the merchant to charge their card periodically. | * '''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. | * '''Merchant initiated payment''': The payer authorizes the merchant to charge their card without restrictions. | ||
| Line 43: | Line 43: | ||
<div style="border: 1px solid #aaa; background-color:#eee; font-size: 0.8em; padding:5px 10px;"> | <div style="border: 1px solid #aaa; background-color:#eee; font-size: 0.8em; padding:5px 10px;"> | ||
Explanation:<br/> | 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/> | '''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/> | '''Amount''': specifies whether the amount of the payments can change from payment to payment or must be the same.<br/> | ||
| Line 48: | Line 49: | ||
'''Liability''': describes the entity who is liable for the payment in case of fraud | '''Liability''': describes the entity who is liable for the payment in case of fraud | ||
</div> | </div> | ||
To help you decide on a suitable scenario, please use the decision chart graph below: | |||
[[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}} | |||
== 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. | |||
{|class="wikitable" | |||
|- | |||
! Scenario | |||
! Initial payment | |||
! Subsequent payments | |||
|- | |||
| One-click payment || ✔️ || ✔️ | |||
|- | |||
| Recurring payment || ✔️ || | |||
|- | |||
| Merchant initiated payment || ✔️ || | |||
|- | |||
|} | |||
* merchant has to maintain a new identifier for every new category of | * merchant has to maintain a new identifier for every new category of | ||
| Line 62: | Line 87: | ||
{{NotificationBox|title=IMPORTANT|text=Starting from January 1 the [[3DSecure|3DS authentication]] will be mandatory for all of our partners!|color=# | {{NotificationBox|title=IMPORTANT|text=Starting from January 1 the [[3DSecure|3DS authentication]] will be mandatory for all of our partners!|color=#20c400}} | ||
== What happens if I don't change my implementation == | == What happens if I don't change my implementation == | ||
TODO | TODO | ||
Revision as of 21:19, 18 November 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 (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:
- 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.
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.
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 chart graph below:
File:3ds-recurrencetype-decision.jpg
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 | ✔️ |
- 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:
RecurrenceIdfor 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.
What happens if I don't change my implementation
TODO