Collecting Card Information
NoteThere 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 three ways in which you can collect and tokenize a customer’s card information. The option you choose depends on your requirements and the PCI scope you are willing to accept:
Use our REST API to tokenize a user’s card information (this is your method of choice for integrating PaymentsOS in a native mobile app as well). When using this method, you collect a user’s card information yourself and then invoke the Create Token API from either your server or a native mobile app. If you invoke the API from your server, you must be SAQ-D compliant. If you invoke the API from a native mobile app, your compliancy requirements are reduced to SAQ-A as per the PCI Council’s current assessment (since each mobile device runs its own app instance, the chance of widespread hacks is lower).
Use our Secure Fields Form to collect card information from an embedded HTML form that uses secure fields. When using this option, PaymentsOS generates the card details input fields, handles the logic of grabbing the card information and sends it on 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 CardsIf 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
customerobject 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
untokenized and a
credit_card in a Create Authorization, Create Charge or Create Credit request.
Topics in this Section
The Secure Fields Form is an HTML form that you can include in your site to collect a user’s card information.