Store a Card (Direct API)

The Store Paycard endpoint lets you send raw card data directly to PCI Booking via API. PCI Booking stores the card securely and returns a token.

Using this method means your system handles raw card details, which puts you in scope of PCI DSS compliance. We strongly recommend using this method only for:

Card migration. Moving cards from another storage system or third-party vault to PCI Booking.
Temporary workaround. Handling service interruptions where other tokenization methods are temporarily unavailable.

For all other scenarios, use Card Entry Form, Card By Link, or Payments Library. These methods keep card data off your servers entirely.

Prerequisites

Your system must be PCI DSS compliant to use this method, because it requires handling raw card numbers. If you are not PCI DSS compliant, use one of the other tokenization methods listed above.

Before starting a migration, ensure you have:

A valid PCI Booking API key (sandbox for testing, production for the actual migration)
PCI DSS compliance certification for the system sending card data
A clear inventory of the cards to migrate, including which fields are available (card number, expiry, CVV, cardholder name)

How It Works

Send card details directly to the Store Paycard API. PCI Booking stores the card securely and returns a token in the Location response header.

curl -X POST "https://service.pcibooking.net/api/payments/paycard?saveCVV=true" \
  -H "Authorization: APIKEY your-api-key" \
  -H "Content-Type: text/xml" \
  -d '<BankCardDetails xmlns="http://www.pcibooking.net/reservation" schemaVersion="1.0">
    <BankCard>
      <Type>Visa</Type>
      <Number>4111111111111111</Number>
      <NameOnCard>John Doe</NameOnCard>
      <ExpirationDate>
        <Month>12</Month>
        <Year>2028</Year>
      </ExpirationDate>
      <CVV>123</CVV>
    </BankCard>
  </BankCardDetails>'

The response returns the token URI in the Location header. Include saveCVV=true when the CVV should be stored with the token - otherwise it is discarded. See the API reference for the full list of fields and query parameters, and Card Data XML Structure for the body schema.

Migration Steps

Check your scope. You hold the cards, so the systems that send them are in PCI DSS scope for the migration. See PCI Scope and Compliance.

Choose the options for each call. These query parameters control what PCI Booking stores and checks:

Parameter	Default	What it does
`saveCVV`	`false`	`true` stores the CVV with the token. With `false`, the CVV is discarded.
`validateLuhn`	`true`	Checks that the card number passes the Luhn check. Set it to `false` only for known test numbers.
`validateExpiration`	`false`	`true` rejects cards that have already expired. With the default, expired cards are stored.
`eliminateCardDuplication`	`false`	`true` returns the existing token when the card is already stored. With the default, each call creates a new token.
`ref`	none	Your own reference for the card, which you can use later to find the token.

Test in sandbox first. Run your full migration script against the sandbox environment with test card numbers to validate the integration and error handling. Then run it in production: sandbox tokens do not move to production.
Migrate in batches. If migrating a large volume of cards, break them into manageable batches and track progress. This makes it easier to resume if something goes wrong.
Map old references to new tokens. Maintain a mapping table between your existing card references and the new PCI Booking tokens so you can update all dependent systems.
Check a sample. Call Retrieve Token Metadata on a sample of the new tokens.
Set CVV retention if you stored CVVs. Set a CVV retention policy on each token within 60 minutes of storing it. Otherwise your account-wide default applies.
Delete the source data. Once the migration is complete and checked, permanently delete all raw card records from your source systems.

Migrating from another vault provider? Ask support@pcibooking.net whether a direct vault-to-vault transfer is possible. Include the name of the current provider and the number of cards.

Start Here

Getting Started

Concepts

Guides

Capture Cards

Payments Library

Manage Tokens

Use Tokens

Account Configuration

Additional Functions

Reference

Support

Store a Card (Direct API)

Prerequisites

How It Works

Migration Steps

Next Steps

Token Management

Capture Cards Overview

​Prerequisites

​How It Works

​Migration Steps

​Next Steps

Token Management

Capture Cards Overview

Prerequisites

How It Works

Migration Steps

Next Steps