Fight online fraud with experimental API

What happens when you combine a tech company with a bank? You get innovative solutions to removing friction from the online shopping experience. With our new Virtual Card Numbers API, Capital One is building an experimental service that simulates creating virtual card numbers for online shopping. And we want your feedback on it while we iterate on the design and work toward the final product.

With the growth of online and mobile commerce, the average consumer now has their card stored on file with dozens of recurring billers and online merchants. This increases exposure of customer’s credit card information, and can cause disruption to the payment process if the customer’s card gets reissued or replaced.

Distinct from the credit card number and unique to each merchant, virtual card numbers can limit exposure of sensitive card information because the merchants do not need to handle the credit card number. Virtual card numbers can also help increase sales by preventing disruption to the payment process; when the customer’s card is reissued, the virtual card number stored on file remains active and is now linked to the new (real) card number.

Virtual card numbers use payment tokenization to provide a solution that both consumers and merchants stand to benefit from:

Virtual card numbers use the same payment rails as a physical card—each virtual card number has a unique 16-digit card number (one for each merchant), a security code, and an expiration date. 

The Capital One DevExchange was launched in 2016 with the mission of opening up our APIs and letting developers co-create experiences with our products. To better serve merchants, consumers, and payment processers, we’ve recently released Virtual Card Numbers—an Experimental API that lets developers simulate creating virtual credit card numbers for customers who have a Capital One credit card. This Experimental API was designed to harness the power of tokenization and virtual card number technologies to improve the ecommerce experience.

Currently, we envision two main payment tokenization & virtual card API use cases: New Customer and Existing Customer Enrollment.

New Customer

The first use case is around how we issue virtual cards for more seamless online transactions.  In this use case, once a Capital One cardholder is ready to checkout from an online store, they can log into their account and use the Virtual Card Numbers API to easily create a unique virtual card number for use at that merchant.

Existing Customer Enrollment

Another use case is around updating existing card information. If a customer has a physical card number stored on a merchant site, with customer permission it can be replaced with a virtual card to increase control and security. Here, the merchant can proactively ask for that physical card number to be replaced with a virtual card which allows for uninterrupted spending.

Want to contribute feedback on the use cases for the Virtual Card Numbers API? Check out the product page and click on the Feedback tab to let us know what you think.

Capital One has a rich set of sandboxes for you to interact with our production and experimental APIs. As an experimental API, Virtual Card Numbers is currently a mock service and can only be used to provision a token in this environment. As you’ll see in the API documentation, there is a public set of credentials that you can use for this step.

Once you’ve done this, you’ll get back a standard token which can then be used with the Virtual Card Number API.

Here we have another endpoint. Underneath payment services is where all the different API endpoints live: adding a card, updating and swapping a card with the merchant, disabling and decommissioning a card.

Once that is done, you will get back an encrypted response that contains all the confidential information needed for a customer to use the card.

The last step is decrypting the card. We’re using encryption from OpenSSL to encrypt and de-encrypt. Once you de-encrypt and unpack this, you can access additional information about the card—a nickname, a card number, an expiration date, and address, etc.—all the information a customer needs to use a credit card on the traditional payment rails.

There are also some neat things that can enable experiences on your payment flows or other work flows. Things like:

• The card art.

• The last 4 digits of the card to mitigate customer confusion and potentially aid in in-store returns.

• The product family (i.e., Quicksilver, Venture, etc.) so the customer can access card rewards and protections associated with that card type.

There are also additional endpoints to update a virtual card and to report merchant activity such as updated and decommissioned virtual cards.

Want to contribute feedback on the technology behind the Virtual Card Numbers API? Check out the product page and click on the Feedback tab to let us know what you think.