- Get Started
- Guides
- Integrations
- References
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Corporate
- Sender
- Recipient
- Merchant
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Payment Methods
- Transaction Flows
- Regression Testing
- Data Retention Policy
- API Reference
- Support
COPYandPAY Network Tokens
Last updated:April 30, 2024
COPYandPAY allows you to securely collect card data from shoppers and initiate provisioning of a network token with the respective card network. While the network token is being provisioned, you are immediately receiving a registration token to store it for future usage e.g. recurring payments, one-click payments.
To better understand network tokens in eCommerce and inStore, please read
Tokenization Guide.
To know which acquirers do support network tokens, please reach out to your Customer Success Manager.
To know which acquirers do support network tokens, please reach out to your Customer Success Manager.
Use cases
Standalone tokenization
The merchant collects card data from shopper via widget and initiates the registration tokenization. No payment request/flow involved. A registration token is synchronously provisioned and returned to the merchant. The registration token can then be used in subsequent payments. In the background, a network token is being provisioned by the card network with Issuer involved in the token approval process to make it active for payments.
How it works
Prepare the checkout
Send the request parameters server-to-server to prepare the registration form.
Create the registration form
Display the registration form on your checkout page. Shopper submits the card information.
Network token provisioning for the collected card data is automatically triggered with card network.
1. Prepare the checkout
Perform a server-to-server POST request to prepare the checkout with the required customer data, including createRegistration=true
but excluding paymentType. The response to a successful request is an id
required in the second step to create the registration form.
Sample request:
2. Create the registration form
Create the registration form by adding the following lines of HTML/JavaScript to your page:
- With the
checkoutId
received from first step<script src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId={checkoutId}/registration"></script>
- With the
shopperResultUrl
as the page on your site where the end consumer should be redirected after the tokenization is complete<form action="{shopperResultUrl}" class="paymentWidgets" data-brands="VISA MASTER AMEX"></form>
Sample form:
3. Get the registration status
Once the tokenization request is processed, the customer is redirected to your shopperResultUrl
along with a GET parameter resourcePath
.
resourcePath=/v1/checkouts/{checkoutId}/registration
A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the card network. The provisioning request takes time with issuer involved in the token approval process. The network token will be fetched with the subsequent payment attempt.
"transactions":[ { "reason":"tokenization", "transactionId":"<UUID>", "clearingInstituteName":"TokenVault", "paymentType":"TK", "result":{ "code":"000.000.000", "description":"Transaction succeeded" } } ]
The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN. However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.
"card":{ "bin":"<bin>", "last4Digits":"<last4>", "holder":"<holder>", "expiryMonth":"<month>", "expiryYear":"<year>" }
Sample request:
4. Send payment using the registration
Perform a server-to-server POST request over the registration token retrieved in the previous step.
Alternatively, use one-click checkout to authorize the payment with a
selected stored registration token.
A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from the card network. The payment authorization continues with real card data if no network token is yet active for payments.
"transactions":[ { "reason":"tokenization", "transactionId":"<UUID>", "clearingInstituteName":"TokenVault", "paymentType":"TF", "result":{ "code":"000.000.000", "description":"Transaction succeeded" } } ]
Sample request:
Prepare the checkout
Send the request parameters server-to-server to prepare the registration form.
Create the registration form
Display the registration form on your checkout page. Shopper submits the card information.
Network token provisioning for the collected card data is automatically triggered with card network.
1. Prepare the checkout
Perform a server-to-server POST request to prepare the checkout with the required customer data, including createRegistration=true
but excluding paymentType. The response to a successful request is an id
required in the second step to create the registration form.
Sample request:
2. Create the registration form
Create the registration form by adding the following lines of HTML/JavaScript to your page:
- With the
checkoutId
received from first step<script src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId={checkoutId}/registration"></script>
- With the
shopperResultUrl
as the page on your site where the end consumer should be redirected after the tokenization is complete<form action="{shopperResultUrl}" class="paymentWidgets" data-brands="VISA MASTER AMEX"></form>
Sample form:
3. Get the registration status
Once the tokenization request is processed, the customer is redirected to your shopperResultUrl
along with a GET parameter resourcePath
.
resourcePath=/v1/checkouts/{checkoutId}/registration
A token transaction history is provided in the response to let you know that the network token provisioning kicked-off with the card network. The provisioning request takes time with issuer involved in the token approval process. The network token will be fetched with the subsequent payment attempt.
"transactions":[ { "reason":"tokenization", "transactionId":"<UUID>", "clearingInstituteName":"TokenVault", "paymentType":"TK", "result":{ "code":"000.000.000", "description":"Transaction succeeded" } } ]
The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN. However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.
"card":{ "bin":"<bin>", "last4Digits":"<last4>", "holder":"<holder>", "expiryMonth":"<month>", "expiryYear":"<year>" }
Sample request:
4. Send payment using the registration
Perform a server-to-server POST request over the registration token retrieved in the previous step. Alternatively, use one-click checkout to authorize the payment with a selected stored registration token.
A token transaction history is provided in the response to tell you that the network token is attempted to be fetched from the card network. The payment authorization continues with real card data if no network token is yet active for payments.
"transactions":[ { "reason":"tokenization", "transactionId":"<UUID>", "clearingInstituteName":"TokenVault", "paymentType":"TF", "result":{ "code":"000.000.000", "description":"Transaction succeeded" } } ]
The network token BIN (Bank Identification Number) is different than the original PAN (Primary Account Number) BIN. However, the original PAN BIN is provided in the response to help you with a better post-authorization real issuer BIN management.
"card":{ "bin":"<bin>", "last4Digits":"<last4>", "holder":"<holder>", "expiryMonth":"<month>", "expiryYear":"<year>" }
Sample request: