Skip to main content
Ideal for: Charging a card the customer has already authorised — repeat purchases, usage-based billing, top-ups — without asking for card details again.
Tokenisation or a subscription? With tokenisation you decide when to charge and for how much. A subscription charges automatically on a fixed cycle you define in a plan. See the comparison.
The Card Tokenise and Charge API lets you charge a card the customer has already authorised, without handling their card details again. After the initial successful payment with a customer’s card, it is possible to store their card authorisation for future transactions. Merchants that are not PCI compliant can leverage our Simple Checkout or our Sdk Libraries to store the card token securely, which can be used for future charges. To commence the first charge, it is required to follow local regulations that necessitate users to authenticate their card through a two-factor authentication process in the initial charge transaction. This is done to verify that the card is valid and it belongs to the user initializing the transaction and that it can be charged for subsequent transactions. Additionally a minimum amount of NGN 50.00, GHS 1, KES 1, or USD 0.50 is required to be passed in the request body for the first charge.

How it works

1

Charge the card once, with authentication

The first charge must pass two-factor authentication — this proves the card belongs to the customer and may be charged again. Local rules require a minimum first charge: NGN 50.00, GHS 1, KES 1 or USD 0.50.
2

Retrieve the authorization code

Once that payment succeeds, query it to get the authorizationCode. This stands in for the card.
3

Charge again whenever you need to

Send the authorizationCode and an amount — singly, or many at once.
You do not need to be PCI compliant to do this. Use Simple Checkout or an SDK for the first charge, and the card details never touch your servers.

Authentication

Tokenisation calls are authenticated with a bearer token, generated from your public and secret keys.

Authentication

How to generate the token, and which credential every other SeerBit API expects.

Create Card Token

This endpoint requires PCI DSS certification. It receives raw card details on your server, so SeerBit will not enable it for your account without a valid certificate. To tokenise a card without certification, take the first payment through Simple Checkout or an SDK and retrieve the authorization code afterwards — every other endpoint on this page works either way.
POST

Request Sample

The code snippet below shows an example response for creating a card token

Response Sample

The code snippet below shows an example response for creating a card token

Parameter description

Get Card Authorization Code

After the first successful transaction, you can query the transaction with the payment reference endpoint to confirm the status of transaction. The queried payment reference returns the authorizationCode that will be used for subsequent charges. Below is a sample response. GET

Response Sample

Parameter description

Charge Authorisation Token

To charge a card token, simply send the authorizationCode along with the amount to be charged using the charge authorization API POST

Request Sample

The code snippet below shows an example request for charging a token

Response Sample

The code snippet below shows an example response for charging a token

Parameter description

Bulk Charge Token

POST

Request Sample

The code snippet below shows an example response for bulk charging a token

Response Sample

The code snippet below shows an example response for bulk charging a token

Parameter description

The request body is a JSON array, not an object. Each entry takes the same fields as a single charge: The response returns a batchId — use it to query the batch, since individual results settle asynchronously.

Query Bulk Charge with BatchId

GET

Response Sample

The code snippet below shows an example response for querying a bulkchargeToken with the batchId

Notes

  • The first charge is different from every one after it. It needs two-factor authentication and a minimum amount; subsequent charges need neither.
  • Store the authorizationCode, not the card. It is the only thing you need to charge again, and it is safe to keep in your own database.
  • A token is tied to one card. If the customer’s card expires or is replaced, the code stops working — handle that decline by asking them to authorise a new card.
  • Bulk charges are asynchronous. The initial response confirms the batch was accepted, not that the charges succeeded. Poll the batchId or rely on webhooks.
  • Give every charge a unique paymentReference, including each entry in a bulk array — a reused reference is rejected.
  • Confirm each charge server-side before you fulfil — see Verify a payment.