Collecting Card Information

Before you can accept payments using PaymentsOS, you need to collect your customer’s card information. PaymentsOS provides a card tokenization service to safeguard sensitive card data, converting a card’s details to a representative token that you can safely send to your servers.

Note

There are a few details you should be aware of when it comes to tokenization. What you should know about tokenization.

Options for Collecting Card Information

There are several ways to collect and tokenize a customer’s card information. The option you choose to implement depends on your requirements and the PCI scope you are willing to accept:

If you choose to use the REST API method, you will need to tokenize the user’s card information or send us their plain card details. End to End Encryption is also optional for this method, if you are SAQ-D compliant. You can also use the API by invoking the Create Token API from your server (i.e. Server to Server method), for which you also need to be SAQ-D compliant. Note that when you invoke the API from a Native Mobile App, your compliance requirements are reduced to SAQ-A. There are no official PCI Council instructions for Native Mobile Apps used for e-commerce (where the end user makes a purchase from their own device). Yet, since these instances generally involve a single/few users using a specific device, they do not fall under the official card data requirements, making SAQ-A compliance valid and excludes the app side from the PCI Scope. Nevertheless, should your native mobile app be used as a Point Of Sale —you will need a PCI-PA Certification.
If using the Javascript API to collect card information in the browse, you will need to create the payment form and control how the information is collected. The Javascript API then sends the information to PaymentsOS, where it is tokenized. This option reduces your PCI scope, requiring you to be SAQ A-EP compliant.
If using the Secure Fields Form to collect card information from an embedded HTML form, PaymentsOS will generate the card details input fields, handling the logic of grabbing the card information and sending it to our servers for tokenization. This option further reduces your PCI scope, requiring you to be SAQ A compliant.

When card information is submitted using any of these options, PaymentsOS returns a token representation of the card which you must use when accepting payments.

Payment Methods other than Cards

If you want to offer your customers the option of using a payment method other than cards (such as bank transfers or e-Wallets), then you can create a checkout page that lists all available payment methods. For more information, see Building a Checkout Page

What you Should Know About Tokenization

Tokenization is a process that safeguards sensitive card data, converting a card’s details to a representative token.

When you tokenize a user’s card information, PaymentsOS returns a token object. You can see what a token object looks like by filling in the form below and clicking Create Token. Note that you will need your public authentication key to activate the card details input field. Beware that you can only use a test key for this example (login to your PaymentsOS account and grab the key from your Business Unit configuration). For the card number, you can enter ‘5105 1051 0510 5100’.

There are three things you should know about tokenization:

Once a payment succeeded, you will no longer be able to use the same token again. If you want to reuse a token so that customers do not need to repeatedly update their card information, you must first store it in a customer object and then use the stored token in your payment requests. For more information, see Reusing Card Information.
Tokenization does not validate the card, but merely provides a means to protect sensitive card data. For instance, the customer’s credit card could have expired or the card might have been cancelled. This will not be detected when the card information is tokenized, but will be reported back to you by the provider when you perform your first transaction.
The customer’s CVV code is not part of the token. If the provider requires the CVV code in an authorization or charge request, you should pass it to your server in addition to the token itself. Optionally, you can also pass an encrypted CVV code that is returned in the tokenization response (the encrypted CVV code is valid for three hours).

Passing Full Credit Card Details

If you are SAQ D compliant, you can pass full credit card details without using our tokenization service. To do so, you must pass a payment method type of untokenized and a source_type of credit_card in a Create Authorization, Create Charge or Create Credit request.

What’s next?

Since you’re getting started, we’ll show you how to use the Javascript API or Secure Fields Form. Proceed to the option of your choice:

Topics in this Section

Using the Javascript API

You can use our Javascript API to collect and submit the customer’s payment information from the browser using Javascript.

Using the Secure Fields Form

The Secure Fields Form is an HTML form that you can include in your site to collect a user’s card information.

Last modified January 3, 2023