Payment Orchestration Platform

Payoneer’s Smart registrations, Secure storage, and Token management solution lets you manage the sensitive data of your customers safely and conveniently.

Tokenization: Provider and Network-Level Tokens

In a nutshell, the token is a representation of sensitive data of a payment account (e.g. a card number). A system (e.g. merchant) sends the sensitive data to a provider and receives a token in exchange. By receiving and storing the token instead of the sensitive data itself, the calling systems can stay out of high-maintenance security infrastructures. at the moment, there are two kinds of tokens:

  • Provider tokens
  • Network-level tokens (or simply, network tokens)

Provider tokens are issued by payment providers. They are always provider-specific and constitute a lock-in to a single payment service provider, meaning you can’t switch a provider without changing the token. This type of tokens is not sensitive as they are bound to one merchant in order to decrease fraud potential.

Network level tokens (NLTs) can be used across multiple providers*. This kind of tokens is automatically updated when the credit card behind the token is updated. The token won’t be blocked, however, if the card is stolen.
*At the moment, network tokens can be handled by Payoneer but not utilized across multiple providers. However, this is due to change.
Important to know:

  • EMVCo defines a Payment Token (TPAN) as a surrogate value that replaces the primary account number (PAN) in the payment ecosystem. TPAN looks exactly like a PAN and has the same attributes (expiration month, expiration year)
  • Network tokens pass basic validation rules of a PAN, including the Luhn check digit.

Secure storage

Secure storage is an encrypted data storage system for sensitive customer data. The encrypted data is accessible only if you supply a key/password or an access secret. The original sensitive data can be restored if the correct key(s) are provided. This way the secure storage enables provider switching, e.g. using previously entered card data with a new provider.
Naturally, the processing and storage environment needs to comply with the security standards imposed for sensitive data. For credit cards, this security standard is the Payment Card Industry Data Security Standard (PCI DSS).
Payoneer offers provider-independent secure storage and token management with all connected acquirers, banks, and payment service providers.

Smart registrations

On top of scenarios, covered by secure storage and tokenization, Payoneer offers a solution for the following business cases:

  • preferences of customers if several payment accounts are available
  • fallback preferences of merchants if the preferred payment account of the customer has failed or expired
  • lifecycle management of a payment account stored by the secure storage or represented by a provider token (e.g. expiry and update processes)
  • simultaneous handling of tokens for frontend and recurring applications (enabling automated backend processing via customer mandate)
  • automated denial management strategies if a recurring token could not be processed successfully (retry strategies or customer interaction)
  • one-click checkout logic covering different scenarios (e.g. with or without CVV with necessary updates)
  • dual supplier strategies with uniform handling of multiple providers of secure storage and tokenization infrastructures
  • routing strategies with an intelligent distribution of initial transactions to the portfolio providers
  • simultaneous registrations at several providers to enable seamless routing for recurring transactions
  • switching and migration scenarios from one provider to the other

Payoneer Smart registrations is a feature that offers fast account updates, easy provider switching, and secure data storage, at the same time providing the best possible customer experience. The feature covers scenarios that can’t be handled with secure storage and token management alone, including a seamless integration of tokenization logic for all payment providers and a provider-independent secure storage.
Specifically, Payoneer Smart registrations provides:

  • simple handling via a single reference per one customer ID (“Customer Registration ID”); not per stored payment account, provider, or contract
  • management of tokens for multiple cards and preferences among those cards
  • applicability for credit card numbers as well as for all payment methods worldwide
  • expiry management of tokens (e.g. credit card numbers)
  • fast updates of payment details – in case of a required update of the payment account, typically only the expiry date needs to be entered (and not the complete card number, if unchanged)
  • zero-knowledge principle / 2-factor authentication available for the secure storage
  • an option for secure storage entries to be sent to new payment partners worldwide

Zero-knowledge
principle All sensitive data of a payment method can be stored within the proprietary secure storage (PCI Level 1 compliant). The secure storage complies with the zero-knowledge principle and 2- factor authentication. This means:

  • Two separate keys are necessary for access (merchant platform or customer + Payoneer)
  • Neither Payoneer nor anyone else (e.g. NSA or hackers) can access the data

If both keys are provided, the sensitive data can be submitted to an entity or any payment partner. The complete switching logic (insertion of secure storage data) is managed automatically. In secure storage, Payoneer can automatically manage all tokens or other forms of registrations of all integrated payment wallets, PSPs, acquirers, and banks.

Existing provider registrations or tokens of the merchant’s payment partners can be imported into the smart registration storage (customers don’t have to re-enter their data as a result of migration). No management of expired accounts, account updates, or customer preferences is necessary. The secure storage logic is accessible via simple REST/JSON APIs.

Simultaneous provider registrations
Registrations of sensitive data inside secure storage enable a high level of independence from payment providers. However, for applications which work with one-click or recurring payments, a switch from one provider to another usually requires additional authentication (e.g. entry of the verification code) from the customer.

With Simultaneous registrations, at the moment of the first transaction, the merchant can submit data to several providers at once and obtain several authentication tokens, enabling full routing flexibility for recurring transactions.

Direct provider registrations and Payoneer secure storage registrations can be done simultaneously at the initial transaction time, so subsequent recurring/one-click transactions can be routed to different providers, depending on provider availability and routing strategy. If multiple registrations are available, a merchant can choose whether they want to use provider registration or Payoneer secure storage, depending on provider pricing and the routing strategy. Additional Provider/Financial Institution Routes can be added at any time.

Depending on the verification requirements of the provider/FI contract (whether verification code or 3D Secure is not required, or mandatory but can be suspended temporarily), new routes can be added just in time, with a frontend interaction for entering the verification code or in batch mode (migration).

Technical end-to-end use case examples

Initial customer and payment account registration
In this use case, we look at what happens if a customer makes a purchase at your shop for the first time and registers their payment details (one provider is used in the background). The following diagram visualizes the most important system components and the data that is exchanged for this process.

If a customer makes a purchase for the first time, the payment page will come into play. It is typically constructed dynamically through the LIST request. There are different integration scenarios, which are discussed in more detail in Payoneer’s technical documentation. One typical scenario would be:

L1 The merchant server issues the LIST request to Payoneer’s Payment API (Open Payment Gateway, further – OPG) with its Payoneer credentials. The ID of the generated LIST is returned.

L2 The customer client (for example the web browser) receives the LIST ID.

L3 The customer client uses the LIST ID to get the UI components from the OPG and builds the payment page dynamically (for example with the help of Payoneer’s AJAX library).

At this point the customer sees the payment page, chooses the payment method, enters and later submits their payment account details. In this scenario, we assume that the customer has agreed to payment account registration, which will trigger the whole registration process. We also assume that the payment is immediately happening. Payoneer also offers checkout variations like Deferred CHARGEs or Delayed Payment Submission, but they make little difference in the registration process, so we will just look at a simpler flow.

C1 Typically, the sensitive payment account details get submitted via the CHARGE request directly to the OPG (there are different options with regards to available integration scenarios here).

C2 The OPG internally encrypts the payment account data (except CVV/CVC) and stores it inside Payoneer’s Secure storage. The customer registration password will be generated as one of the encryption keys and will be returned.

C3 At the same time, the payment account data will be sent to the payment provider that was chosen for this transaction, based on routing intelligence and the configured routing strategy. This request is authenticated with the merchant’s provider credentials that had been configured in Payoneer’s merchant portal. The provider processes the payment transaction and (in many but not all cases) stores the card/account on its side and generates a token for it. This token and the payment transaction status are returned to Payoneer. Some providers only offer separate registration and payment calls, some offer combined calls, some require a payment for registration. However, the OPG logic takes care of these differences and provides a unified flow to the merchant.

C4 Payoneer stores the provider’s (or network) token. To minimize the risk of fraud, the token is stored outside of the secure storage. The token is bound to a single merchant, so storing it in the secure storage is not required.

CX The OPG sends a status notification to the merchant server with the customer registration ID to identify the customer in the future, and the customer registration password to decrypt and use the payment account details again, if needed (e.g. for other providers). Also, the payment status expressed in Payoneer’s unified status space is returned. The registration data should be stored by the merchant and linked to its own customer registration, so that it can be used when the customer returns (see next section).

This principle is the same for standard and recurring account registrations. The main difference is that recurring registrations of cards do not need the CVV/CVC for a payment anymore, i.e. the merchant can trigger subsequent CHARGEs on their own. Standard registrations often require CVV/CVC input and are typically used for charges with customer interaction.

Returning customer (with standard registration)
In this use case a known customer, who is logged in at the merchant’s site, has a valid payment account registered (using standard registration in this example), and wants to do another purchase with it. Here we will look at a simple scenario with only one provider before we look at multi-provider scenarios.

The process in which the customer selects a previously registered payment account can take place through the conventional payment page and the LIST request. In this case the LIST object will contain the registered account(s). Alternatively, dedicated one-click flows could be used (they will be covered in separate documentation).

L1 The merchant provides the customer registration ID in the call (e.g. LIST) to initialize the repeat payment, so that the OPG can recognize the customer registration and include the registered account into the LIST object for this transaction.

L2 In a LIST scenario, the LIST object ID will be passed to the client as before.

L3 The client will fetch the corresponding UI elements. In the case of standard registrations (as opposed to recurring registrations) there will be forms that require CVV/CVC input from the customer, but nothing else. A masked account number (in the style of 4231 **** **** 1234) will be provided to make the card identifiable for the customer).

The payment page with a registered payment account and CVV/CVC input form typically looks like the following:

When the customer proceeds with the payment, the following steps in the CHARGE process will take place:

C1 The CVV/CVC entered by the customer is submitted to the OPG via CHARGE request.

C2 Since the customer registration ID was provided earlier, the existing provider token can be retrieved from Payoneer’s internal storage.

C3 The provider token gets combined with the CVV/CVC and submitted to the payment provider to make the debit.

CX The transaction status will be returned to the calling client as well as sent via status notification.

Note that in this case Payoneer’s secure storage didn’t need to be accessed as we were using a provider token. The original payment account data was not required. The customer registration password wasn’t used either, although it is good practice to supply it anyway together with the customer registration ID.

Provider contract switch
You might want to switch from one provider to another because their conditions are better. In this case the OPG will use the stored original account data to make the payment through a new provider.

The preparation steps L1-L3 are the same as before. Just note that in this case the customer registration password needs to be supplied. To be prepared for cases like this, your system should always send the customer registration password.

In the following scenario, the route to the original provider that kept the account registration and provided a token is not available anymore. The reason could be a deliberate switch to another provider by the merchant, routing strategy, enforcing tokenization with new providers when a customer is present, or exceptional cases like a temporary provider downtime. This results in the following CHARGE process:

C1 The customer provides CVV/CVC if needed (depends on configuration).

C2 Since the existing provider registration cannot be used for this transaction, the OPG will decrypt the original payment account data (that doesn’t have CVV/CVC) from its secure storage using the customer registration password.

C3 The payment account data gets combined with the CVV/CVC that was provided by the customer and sent through an alternative route (according to the routing strategy in place) to a new provider.

As a result, the customer made a purchase using the standard account registration, while a new provider was used in the background.

Note that if the customer registration password is not supplied in a situation where no route with usable provider registration exists, the registered account cannot be used as there is no way to decrypt the data. Therefore, it will not be shown as a payment option in a LIST session.

Simultaneous registrations for recurring payments
The above-mentioned use cases work well with standard registrations where CVV/CVC is provided by the customer for each transaction. However, with recurring registrations the situation is more complicated.

A provider token for a recurring registration will allow debits on that card without providing the CVV/CVC. Therefore, it can be used for merchant-initiated transactions and one-click scenarios.

However, since a provider token is only valid for one provider and the CVV/CVC cannot be stored by Payoneer permanently for PCI compliance reasons, provider switching poses a challenge. But Payoneer provides a solution for this case.

In order to enable provider switching later, a registration can be performed simultaneously with multiple providers at the point where the CVV/CVC is present, i.e. at the time of the initial checkout (C3 and C4 in the diagram). For this, individual contracts can be configured in Payoneer’s Merchant Portal to execute simultaneous registrations, even if the payment transaction itself does not get routed to them. As a result, the OPG will receive two or more provider tokens and store them.

For subsequent charges, there are routes available for multiple providers, even for recurring charges without a provided CVV/CVC. Based on the current routing strategy, the best provider for this transaction will be chosen. Also, the route to one provider can be permanently disabled by a merchant, so that a switch to the remaining providers will take place.
Note 1: For a simultaneous contract registration both standard and recurring registrations can be activated individually.
Note 2: Simultaneous registrations are not possible for the cases, when 3DS is mandated for customer-initiated transactions (for example in the PSD2 area).

Account updates
Payoneer offers a possibility to end customers to update their accounts without making a payment. The main use case here is updating the expiration date of a registered card. The integration works very similar to that of the payment page, therefore very little extra effort is needed on a merchant’s side to introduce this functionality.

When the customer submits the new expiration date together with the CVV/CVC, Payoneer will change the data in its Secure storage and try to update all existing provider registrations.

However, it may happen that changing an existing registration on the provider’s site is not allowed by the provider itself. In these cases, Payoneer will try to remove the old registration and create a new one with the updated data. However, there is still a possibility that the provider does not allow a standalone registration. To make the new registration possible, Payoneer will try to do a preauthorization with a minimum amount that gets cancelled right away.

There is always a chance that these kinds of workarounds are not possible with a certain provider, but Payoneer will always try multiple strategies to get to the intended outcome. As a result, you as a merchant do not have to care about implementing specific flows for different approaches of individual providers.

Updates with network level token
The card data behind NLT is updated automatically.

Conclusion
These use cases are typical examples of how Payoneer’s registration intelligence and token management can give you maximum flexibility and provider independence in a multi-provider setup. All provider differences are hidden behind the OPG abstraction, so that your system only needs to care about a single customer registration.

About Payoneer

Payoneer (NASDAQ: PAYO) is the world’s go-to partner for digital commerce, everywhere. From borderless payments to boundless growth, Payoneer promises any business, in any market, the technology, connections and confidence to participate and flourish in the new global economy. Since 2005, Payoneer has been imagining and engineering a truly global ecosystem so the entire world can realize its potential. Powering growth for customers ranging from aspiring entrepreneurs in emerging markets to the world’s leading digital brands like Airbnb, Amazon, Google, Walmart and Upwork, Payoneer offers a universe of opportunities, open to you.

If you have any questions regarding this document or our payment orchestration platform, please don’t hesitate to contact us.

enterprisesales@payoneer.com