On this Page
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 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.
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).
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
untokenized and a
credit_card in a Create Authorization, Create Charge or Create Credit request.
The Secure Fields Form is an HTML form that you can include in your site to collect a user’s card information.