NOTE: You should be fully PCI compliant if you wish to perform tokenization requests server-to-server (as it requires that you collect the card data). If you are not fully PCI compliant, you can use the COPYandPAY tokenization tutorial to collect the payment data securely.

Tokenization allows you to store the payment data for later use. This can be useful for recurring and/or one-click payment scenarios.

The Developer Guide describes how you can store the data using our Server-to-Server API, how you can subsequently use the stored card details for a one-click payment and how to delete stored data.

  • Storing the payment data
  • Using the stored payment data
  • Deleting the stored payment data

Storing the payment data

There are two methods for creating a token

  1. Store the data during a payment
  2. Store the data as stand-alone

Store/add/save the Card using Tokenization & Registration

If you use a workflow like the below Method 2 Storing the Data during a payment:

1. Customer adds card
2. Your systems store card token
3. When amount is due, stored card is billed

Please see sample code below - please also refer to our
technical documentation for conclusive instructions:


1.  Customer adds card

curl https://eu-test.oppwa/v1/payments \






card.number= 4111111111111111

card.holder=Jane Jones









This will validate the card and once validated, store the card details and return a payload.


This R1.00 PA is done to check that the card being added is valid, before you store the card for future billing.

This R1.00 amount should return to the customer's account after a period ; i.e, their balance will increase by R1.00 when the PA falls away (period differs from bank to bank).

If this R1.00 PA is not done, first of all the card storage transaction cannot be 3DSecure authenticated and secondly, you may store cards that later cannot be billed at a later stage. This does not ensure that you can charge the full amount (since most likely the basket value would be greater than R1.00), but it at least checks with the bank that the card is valid.


2. Your systems store card token

The payload (response from our systems) will include a registrationID, which you can save as the token of the card. You can then make payments on this stored card by referencing its token. Please only store the token in your database if the PA transaction is successful


3. When amount is due, stored card is billed

curl https://eu-test.oppwa/v1/registrations/{id}/payments \


-d "amount=92.00" \

-d "currency=ZAR" \

-d "standingInstruction.mode=REPEATED" \

-d "standingInstruction.type=UNSCHEDULED" \

-d "standingInstruction.source=MIT" \


Please note that the entity ID here should be the recurring entityID -d "authentication.entityId=XXXXXXXX" \

IF you were only supplied one entityID, as long as the recurringType parameter indicates REPEATED, this will still direct the transaction to skip 3DSecure


If you would want to take the subsequent payments through 3DSecure, then you would use the 3DSecure entityID and remove the recurringType=REPEATED parameter. This will make sure the transaction triggers an OTP for 3DSecure authentication, rather than skip 3DSecure as required for subscription models, with no customer interaction.

In this case, you would have

curl https://eu-test.oppwa/v1/registrations/{id}/payments \


-d "amount=92.00" \

-d "currency=ZAR" \

-d "paymentType=DB" \

-d "standingInstruction.mode=REPEATED" \

-d "standingInstruction.type=UNSCHEDULED" \

-d "standingInstruction.source=MIT" \


Please note that the entity ID here should be the 3DSECURE entityID -d "entityId=XXXXXXXX" \

If you only have one entityID, this will by default be the 3DSecure entityID.

Please see how to handle the 3DSecure* redirect here

*Please note that the Card Scheme (VISA and MASTERCARD) 3D Security Standard 2.0 mandated change over to use the 3D Security 2.0 Standard