1/ Simple transaction including a Token
As a merchant or a platform, if you are not PCI-DSS compliant Level 1, you are not allowed to stock or use any bank data.
You have then to use a token to charge your transaction by credit card without using any sensible data and having the same agility as a PCI-DSS compliant actor.
NB : the client, your "customer", is the consumer executing a payment.
You receive then a cardTokeId that allows you to initiate a transaction object from your servers without manipulating any credit/debit card number.
Infographic regarding a single payment workflow
NB: you also have the possibility to register, from this transaction stage, a customer that contains the card object including all card data. (please refer to the single payment flow infographic). This step would be useful if want to reiterate a transaction with the same card later on.
2/ Recurring transaction with a Customer
Thanks to the customerID generated (containing the sub-object card with payment data), you can proceed to a new transaction without asking for his/her credit/debit card number to your client once again.
There a several ways of using customerID:
- 1 clic payment, 1 clic upsell, 1 clic cross sell
- Subscription payment
- X multi payment - installment
3/ Direct transaction without Token
This case in not recommended as it necessitates from your side the full load of the secure PCI-DSS process.
Nevertheless if, as a merchant or a platform, you are PCI-DSS level compliant, you can send directly the payment cards to the transaction object without using the "token.js" service. It supposes that no "tokenization process" is done by CentralPay.
You send directly the cards to the API in the transaction object. Those cards are stocked and managed from your side. In that specific case, you do not have to create a customer during a new transaction because you already use the payment data stocked in your PCI-DSS environment.