Token payment: Difference between revisions
Line 75: | Line 75: | ||
== Using the token == | == Using the token == | ||
To use an already registered token for a payment, the <code>InitiateRecurrence</code> should be set to <code>false</code>. This tells the Barion API to use the token for payment instead of only registering it. The token should be specified in the <code>RecurrenceId</code> property. | To use an already registered token for a payment, you have to use the same [[Payment-Start-v2|/Payment/Start]] API endpoint but the <code>InitiateRecurrence</code> should be set to <code>false</code>. This tells the Barion API to use the token for payment instead of only registering it. The token should be specified in the <code>RecurrenceId</code> property. | ||
There is no amount limitation for the token payment and the payment scenarios could be changed as well for the token charge. This means that the token payment can be reservation even if the original payment was an immediate scenario. | There is no amount limitation for the token payment and the payment scenarios could be changed as well for the token charge. This means that the token payment can be reservation even if the original payment was an immediate scenario. | ||
Line 81: | Line 81: | ||
=== Processing the response === | === Processing the response === | ||
The structure of the response is the same as the normal <tt>/Payment/Start</tt> response just the statuses will be different. In this case | |||
* the payment level '''Status''' will be <code>Succeeded</code> instead of <code>Prepared</code> | |||
* the transaction level '''Status''' will be <code>Succeeded</code> instead of <code>Prepared</code> | |||
* the '''RecurrenceResult''' will be <code>Successful</code> instead of <code>None</code> | |||
Although this is an immediate response that indicates a successful charge the [[Callback_mechanism|callback mechanism]] still will be in motion as well. | |||
=== Possible error responses === | === Possible error responses === |
Revision as of 11:20, 10 February 2017
Token Payment
This payment scenario allows the integrator shop to register a customer (and a funding source) in the Barion system and then later on charge the customer without redirecting it to the Barion system. This means that the customer authorizes the shop to charge its card without typing in the card information again.
The payment process
The process is divided to two major steps:
- Creating the token that represents the one of the customer's funding source (credit card or e-money wallet)
- Using the registered token to charge the customer
Creating the token
To be able to use a token payment scenario first we have to register the token with Barion. The token registration is basically a normal payment with two new properties in the Payment/Start request. This means that we have to make sure that the customer is well aware of the fact that he or she is giving consent to a tokenized payment. The Barion pamyment does not indicate in any way that the payment is a token payment.
The token is registered to the shop and not to the wallet. So if the Barion wallet has multiple shops registered the token can not be shared among them even if the customer is the same.
One of the properties is the InitiateRecurrence
property. This is a bool property, if you set it to true then the payment gateway will consider the request as a token registration. This happens even if the customer is already has a registered token, so you are able to re-register a customer.
The other required property for a token registration is the token itself. This is generated by the shop and has to be unique for every registration. The token should be specified in the RecurrenceId
property of the Payment/Start request. This token should be stored in the webshop database. Make sure that multiple tokens can belong to a single customer because the token is only unique for a specific shop, customer, funding source combination.
An already used RecurrenceId
can be used for re-registration, in this case the new funding source will be registered for the token.
Exmaple JSON request
{
"POSKey": "E31EC263-01DC-40BD-BDF1-38FC7A332434",
"PaymentType": "Immediate",
"PaymentRequestId": "EXMPLSHOP-PM-001",
"InitiateRecurrence": true,
"RecurrenceId": "SHOP-XMLP-TOKEN-ABC-123",
"FundingSources": ["All"],
"Currency": "EUR",
"Transactions": [
{
"POSTransactionId": "EXMPLSHOP-PM-001/TR001",
"Payee": "[email protected]",
"Total": 25.2,
"Comment": "Subsription fee for the first month",
"Items": [
{
"Name": "Website subscription",
"Description": "Website subscription for one month",
"Quantity": 1,
"Unit": "month",
"UnitPrice": 25.2,
"ItemTotal": 25.2,
"SKU": "EXMPLSHOP/SKU/PHC-01"
}
]
}
]
}
Customer selects funding source
After the proper payment preparation the customer is redirected to the secure Barion gateway to choose between funding sources. The funding source the customer selects will be registered to the token. The funding source can either be an e-money wallet od a bank card. This means that even though the customer may own multiple cards only the one that was registered to the token can be used for future token payments. To change the funding source attached to the token a new registration should be requested.
Processing the response
The response is almost the same as to a basic Immediate scenario. The only difference is that there is the RecurrenceResult
property that tells the result of the token registration. This could be either
- Successful: the token is registered and live, can be used for payment
- Failed: the token registration was not successful, the token can not be used
- None: this could only happen if no token payment was requested
Possible error responses
Error code | Description |
---|---|
RecurringPaymentNotAllowed | The token payment is not allowed for the shop identified by the POSKey. Contact Barion to request this feature. |
Using the token
To use an already registered token for a payment, you have to use the same /Payment/Start API endpoint but the InitiateRecurrence
should be set to false
. This tells the Barion API to use the token for payment instead of only registering it. The token should be specified in the RecurrenceId
property.
There is no amount limitation for the token payment and the payment scenarios could be changed as well for the token charge. This means that the token payment can be reservation even if the original payment was an immediate scenario.
Processing the response
The structure of the response is the same as the normal /Payment/Start response just the statuses will be different. In this case
- the payment level Status will be
Succeeded
instead ofPrepared
- the transaction level Status will be
Succeeded
instead ofPrepared
- the RecurrenceResult will be
Successful
instead ofNone
Although this is an immediate response that indicates a successful charge the callback mechanism still will be in motion as well.
Possible error responses
Error code | Description |
---|---|
InvalidRecurrenceId | The token specified in the RecurrenceId is invalid. Check if the token registration was successful.
|
RecurringPaymentDenied | Something happened to the user since the token registration, either deleted, suspended or blocked. The payment s not allowed in these cases. |
InsufficientFunds | If the original payment was with e-money wallet and the customer doesn't have enough money to fulfill this charge this error happens. |
OriginalPaymentWasntSuccessful | This means that the token belongs to an originally unsuccessful payment so this token can not be used anymore. This could only happen if the original payment was financed with a credit card. |