PCI Booking provides a simple, Restful, API to perform all actions regarding a credit card.

PCI Booking is made up of several application areas. This developers site contains a guide and a reference manual for each application area.

  • The guides allow software architects and designers to have a broad view on the system operation and easily pick up those components which can fit the best different application scenarios.
  • The reference manuals allow developers to have a clear understanding of which methods are available, what input parameters are required for each method and the expected results of each.

Retrieve card from third party and associate with third party

In some cases, the situation may come up that two companies are working together as partners (whereby company A captures the card from a third party and then needs to relay it to company B) and both companies are customers of PCI Booking.

Yes, in this case, just like in any other case where relaying a card is needed, company A can use the relay method to send the card to company B's API and then company B will use the Gateway in order to tokenize the request as it comes in. However, in this scenario, both companies pay a transaction fee (one for token replacement and one for tokenization) - in addition, both companies will now incur a storage fee for each of their card tokens.

Since both companies are using PCI Booking, they can simply share the existing token and allow the other to perform actions on the token.

Stage #1: Tokenize the card

The first step in this process would be for company A to tokenize the card with PCI Booking. This can be done with one of the several methods that PCI Booking offers for tokenization:

The end result of any of the above methods is that the card will be tokenized in PCI Booking and company A will hold the card token (A URI to the card details).

Stage #2: Associate the card with company B

In order to allow company B to perform actions on the token, company A will need to first "associate" the card token with the company B.

In order to achieve this, once the card has been tokenized, company A will need to use the Associate Paycard method to associate the token with company.

After associating the card token with company B, company A can simply send company B the token (as this is not protected information, it can be sent in the clear - for example, in an email).

Stage #3: company B uses the card token

Once associated with the card token, company B can perform any action on the token just as if it were created by them originally.
This includes charging the card via the Universal Payment Gateway, relaying the card to a third party, displaying the card details, deleting the token, etc.

Ownership of the token

A token is owned by the PCI Booking customer that created the token in the first place. If a token is associated with another PCI Booking customer, that customer will have the ability to perform actions on the token, however ownership of the token (and as such, responsibility for the token) remains with the user that created it initially.

All fees (for all actions performed on the card) will be made out to company A; Responsibility for long term storage of the card and the retention policy for the CVV remain with company A.

Stage #4: Remove access from Company B

Based on company A's workflow, they might need or want to remove company B's access from this token.
In order to do this, company A will need to use the Disassociate method and remove the access from company B.

Retrieve card from third party and associate with third party


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.