Token payment upgrade to 3DS: Difference between revisions
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
[[Token_payment|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: | [[Token_payment|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: | ||
# Create an alphanumeric token | # Create an alphanumeric token | ||
# 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) | # 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) | ||
# 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. To make sure that the payer | 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. | ||
{{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 18:50, 16 November 2020
Upgrading token payment implementation to use 3DS
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:
- Create an alphanumeric token
- 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)
- 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.