Customer Profiles: Facilitating Card on File Payments in IXOPAY
Loyal customers are return customers. One thing that return customers want to avoid is having to re-enter their payment details multiple times. Allowing them to choose from previously used payment options makes life easier on them and goes a long way to improving the customer experience and keeping your loyal customer happy. Handling card on file transactions or recurring payments requires storing customers’ payment details securely so they can be reused.
IXOPAY allows you to view customer details including payment instruments and transaction history directly within the platform. You can also use the customer profile API to access and update customer information.
Customer Details in IXOPAY
Customer details (name, billing address, email address etc.) in IXOPAY are stored in customer profiles. As well as storing basic customer details, a customer profile can have multiple payment instruments linked to it, such as credit cards, bank accounts or alternative payment methods like Apple Pay and Google Pay. If multiple payment instruments have been added for a customer, one of the instruments can be set as the preferred payment method. A full transaction history is also available for each of the payment instruments stored in a customer’s profile.
When displaying the checkout page, existing payment instruments stored for the customer can be displayed, with the preferred payment method pre-selected. New payment instruments can be stored when a customer successfully completes a purchase. This requires a check box on your checkout page, e.g. “Save payment details”.
Customer profiles are in turn stored in so-called containers in IXOPAY, which group together customer profiles. These containers can be assigned to payment providers (or more accurately, the connectors used to connect to the providers). Whenever a customer chooses to save their payment details, their customer profile is added to the container linked to the provider used to process the transaction.
Segregating and Sharing Customer Profiles within a Corporation
IXOPAY uses so-called tenants and sub-tenants to depict the structure of an organization, e.g. to represent a company’s regional hierarchy (global HQ, regional HQ, local branches) or organizational structure (e.g. product lines or divisions). Access rights can be applied using this structure to ensure a separation of data.
Customer profile containers can be shared between sub-tenants. For example, a global merchant may have tenants representing regional markets, such as “North America” and “EU”. The EU tenant then has a number of sub-tenants, e.g. “Spain”, “Benelux”, “France” etc. In this setup, payment details can be shared between tenants in Europe, by creating a container at the EU tenant level and enabling the Shared with Subtenants option in the container for the “EU” tenant. However, tenants in the US or Canada (sub-tenants of the “North America” tenant) cannot access these customer profiles. This setup ensures that customer details are not shared with entities outside the EU, in line with GDPR requirements.
Storing Payment Details Securely
Payment details are stored in IXOPAY’s secure vault. As well as credit cards, the IXOPAY vault can store other payment instruments, such as Apple Pay, Google Pay and IBANs. Storing payment details in a secure vault is not only best practice; storing credit card details is governed by PCI DSS. There are various levels of PCI DSS certification, with more stringent requirements applying to businesses who handle and store credit card account information directly. Were merchants to store this payment information themselves, they would need to meet these PCI DSS requirements. Using a third-party solution like the IXOPAY Secure Vault, which is PCI DSS Level 1 certified, reduces merchants’ PCI DSS scope and the associated costs.
Reducing PCI Scope with Tokenization
In order for merchants to be able to access the payment information stored in the vault for future transactions, the payment details are tokenized. This means that a unique identifier is generated by IXOPAY that references the payment details in the vault. This token does not contain any payment data, so does not pose a security risk. If a malicious actor gains access to the token, they cannot reverse engineer the underlying payment data from the token.
For credit cards, storing tokens instead of payment details significantly reduces a merchant’s PCI DSS scope. The same method can be applied to other payment details, such as bank accounts. Instead of storing the IBAN locally, merchants simply use a token to reference this information. Once a payment instrument has been tokenized, the token can simply be included in subsequent transactions, rather than the IBAN.
An advantage of using IXOPAY to tokenize payment details is that you can use the same token for transactions processed by any payment provider. While payment providers will also offer tokenization services, the tokens generated this way are only valid for that provider, leading to vendor lock-in and a high degree of dependence on that specific provider for recurring and card on file transactions. The independence that IXOPAY offers is particularly beneficial for merchants using a multi-acquirer setup with smart routing and fallback options, or for high risk merchants who face the very real risk of losing their payment provider at short notice.
Working With Customer Profiles
Customer profiles can be accessed from the user interface in IXOPAY. You can view all the customer profiles in a container as well as individual customer profiles, the payment instruments linked to that profile (categorized by type) and the customer’s transaction history. Customer profiles can be edited from the UI, the preferred payment method can be changed and payment instruments can be removed from a profile or removed from the vault completely. Customer profiles can also be updated using the customer profile API. Each customer profile has a unique ID that is used to interact with it.
Inside IXOPAY
Technical Overview
From a technical point of view, storing payment details and customer data in IXOPAY’s vault requires a transaction where the withRegister flag in the transaction is set to “true” (for debits, pre-athorizations), or a transaction request of the type “Register”. The withRegister flag or Register transaction type is used to indicate that the payment information should be stored (registered) in the vault. Setting a payment instrument as the preferred instrument is handled using the markAsPreferred flag in the CustomerProfileData object in a transaction request.
The checkout page itself needs to include radio buttons for selecting the desired payment instrument if multiple payment instruments are stored for a customer. A check box is also required when adding a new payment method to give the customer the option to store the payment details. You can find sample code for a hosted payment page in the user manual at the bottom of the Customer Profile page. Information on the formatting of transaction requests including sample requests can be found in the API documentation.
To ensure that sensitive details like credit card numbers and bank account numbers are not handled by merchants directly, IXOPAY’s payments.js library renders separate iFrames for details such as the credit card number and CVV. Data entered in these fields is then sent to the IXOPAY vault directly, where it is tokenized. The token can then be stored in the merchant’s system along with the rest of the information entered by the customer.
Reap the Benefits with IXOPAY
We will cover the IXOPAY vault itself in more detail in a future article, but as you can see, it allows merchants to securely store, tokenize and reuse payment details. This makes it possible to handle card on file and recurring transactions without merchants needing to save payment details themselves - avoiding all the overheads that entails. The more details you store, the easier it becomes to route payments to multiple providers. Different PSPs may have different mandatory fields, and the more data supplied with a transaction, the higher the authorization rates tend to be. Customer profiles play an important role in this process, as well as providing access to a customer’s transaction history and allowing payment details to be shared within a merchant’s tenant structure. Tokenizing payment instruments with IXOPAY also offers merchants greeted independence from payment providers and acquirers.
If you are interested in learning more about storing customer details and payment instruments in IXOPAY vault and how IXOPAY can streamline your payment processes, get in touch!
About IXOPAY
IXOPAY simplifies complex payment processes for global merchants. Merchants can choose between an all-in-one payment orchestration platform and payment optimization modules covering areas such as omnichannel tokenization, 3DS, and network tokens. Depicting the entire transaction lifecycle from checkout to settlement and reconciliation, IXOPAY’s best-of-breed payment orchestration platform is PCI DSS Level 1 certified and highly scalable.
A single API allows merchants to integrate around 200 payment providers offering hundreds of global, regional and alternative payment methods. The platform supports smart transaction routing with cascading, state-of-the-art risk and fraud management, fully automated reconciliation and settlements processing, comprehensive reporting and access to hundreds of acquirers, payment service providers and alternative payment methods.
Trusted by many national and international businesses, IXOPAY has offices in both Austria and the USA.