Collect payment information

Before Spreedly can run a transaction against the gateway you set up, you need to store your users’ payment method information. To minimize PCI scope, this sensitive cardholder data should be added without ever touching your servers.

PCI compliance

Spreedly securely handles and stores sensitive payment method data, which can drastically reduce your PCI compliance burden. However, it is ultimately up to you to evaluate what level of PCI compliance is required for your business.

Spreedly provides a variety of methods to send your customers' data to Spreedly. The methods below are listed with the PCI scope each one incurs. This page also covers Spreedly's iFrame and Express in detail for merchants using those integrations.

Choosing a tokenization method

Spreedly offers several ways to collect and submit payment method information. Each method differs in how much control you have over the checkout experience and how much PCI scope you take on.

When a payment method is added, no transaction or validation is executed. Every method returns a payment method token, and Express also displays the purchase amount you pass to it. A purchase or authorization must still be invoked from a secure, server-side environment.

iFrame

Spreedly's iFrame payment form lets you build a custom checkout experience while card data is stored in the Spreedly vault without ever touching your environment. iFrame remains supported when used with secure tokenization. For new integrations, Spreedly recommends the Checkout SDK.

If you are looking for specific commands or options, please see the iFrame API guides.

Before you begin

You will need your environment key and access secret from app.spreedly.com, your gateway token, and a certificate for generating the secure tokenization parameters. See the step-by-step certificates guide to set these up. It may also help to have test card numbers on hand. A demo payment page that uses iFrame is available in the Sample Payment Frame repository.

Adding iFrame to your checkout page

Spreedly’s iFrame payment form is a Javascript library that provides two Spreedly-managed fields for collecting the credit card number and CVV (the two PCI-sensitive fields of a payment method). Your checkout page places and styles these two fields within your checkout form, and the iFrame returns a tokenized payment method to the host page when the payment method has been successfully submitted.

To add iFrame to your checkout page, please follow this guide.

Express

Spreedly Express uses a pre-built modal to securely send card data to Spreedly. It reduces the development time needed to collect payment information, at the tradeoff of less form customization and flexibility. Like iFrame, Express must be used with the secure tokenization parameters to stay supported. Working examples are available in the Express sample app.

Adding Express

To add Express to your checkout page, please follow this guide.

CVV Number

The Card Verification Value (CVV) is a 3 or 4 digit number located on a card, depending on card type or brand. It is a security code used for card-not-present transactions.

The Payment Card Industry Data Security Standard (PCI DSS) prohibits the storage of the CVV. We at Spreedly pass along the CVV for the first authorize, purchase, or verify event on a given card. Future transactions using that vaulted card do not include the CVV.

Because CVV cannot be stored, Spreedly will only hold the CVV in memory for you for three minutes.

So in summary,

• CVV will be cached for three minutes unless recache or used
  • Recache is an action you can take where you supply Spreedly the CVV and we reset the three minutes. See documentation here
  • Used means it was successfully used in a gateway, deliver, or export transaction.
• The wipe after use can be bypassed with the continue_caching property on a transaction. continue_caching does not extend or reset the three minutes, it just does not wipe it early. See documentation here.

Note: CVV is not verified when a new payment method is added, as a transaction is not executed. Although a token is returned, a purchase or authorization must be invoked from a secure, server-side environment to verify CVV for that payment method.