Card Storage

With our Card Storage API, tokens can be used for recurring billing or to enable one-click checkout. You can store multiple cards against a single customer reference, as well as add, delete, and update cards. All the functionality available where card data is captured can also be called upon in Card Storage including 3D Secure, Dynamic Currency Conversion, Credits and Open-To-Buy (OTB).

We employ a dual-token system whereby each customer is assigned a unique reference (known as a Payer). Each card the customer stores is then saved against that reference. You can easily see all your saved customers and their respective saved cards in our Ecommerce Portal.

In this guide, you'll learn how to use direct API integration to create the necessary customer (Payer) and card (Payment Method) references as well as how to charge them.

A customer (Payer) is a reference you can store multiple cards against. You can also store additional information like address and phone numbers against a customer reference.

Your stored customers can be viewed in Ecommerce Portal in the Customers section, along with their saved cards. There, you can manually charge a stored card or set up a scheduled payment.

It's not possible to delete customers. Only stored cards can be deleted.

Here, we use a random string generator for the customer and card references.

Sample request

We highly recommend that you process an authorization against a card before storing it. That way, you know it’s valid. If you don't want to charge the card, process an Open To Buy (OTB) transaction instead.

Next, we store cards for the customer we created in the previous step.

Sample request

Charging a stored card works the same as a standard authorization, except instead of collected card data you simply send the customer and card references. Global Payments obtains the securely stored card data and builds the authorization message.

Under PCI Compliance rules, the security code (CVN, CVV) cannot be stored. However, if in your application you let the customer use a card they previously saved, you can prompt them for their security code again. Then include the code in the request.

Sample request

Various data elements need to be passed for merchants to manage their own implementation of Credential on File (COF) and Merchant Initiated Transactions (MITs) using our API solution.

For a full description of COF fields and use cases, see our main Credential on File article.

If you're using our Card Storage solution for one-off and recurring transactions, if the first transaction is flagged correctly, we will automatically manage COF, MIT, and Transaction Grandfathering for all subsequent transactions. COF and MIT can be used in the Authorization, Validation (Open-to-Buy/OTB), Charge a Stored Card (Receipt-in), and Validate a Stored Card (Receipt-In-OTB) request types.

For any payment types — regardless of whether you're using our solution or a third-party's or are storing card details yourself — you can manage all of the messaging yourself. To see how to do this, see the example below.

Sample request

<?xml version="1.0" encoding="UTF-8"?>
<request type="auth" timestamp="20180613141207">
  <merchantid>MerchantId</merchantid>
  <account>internet</account>
  <channel>ECOM</channel>
  <orderid>N6qsk4kYRZihmPrTXWYS6g</orderid>
  <amount currency="EUR">1001</amount>
  <card>
    <number>4263970000005262</number>
    <expdate>0425</expdate>
    <chname>James Mason</chname>
    <type>VISA</type>
    <cvn>
      <number>123</number>
      <presind>1</presind>
    </cvn>
  </card>
  <autosettle flag="1"/>
  <!-- Begin CoF Fields -->
  <storedcredential>
	<type>oneoff</type>
	<initiator>cardholder</initiator>
	<sequence>first</sequence>
	<srd></srd>
  </storedcredential>
  <!-- End CoF Fields -->
  <sha1hash>87707637a34ba651b6185718c863abc64b673f20</sha1hash>
</request>

Explore more functionality to enrich your application.