Skip to main content
Recurring payments or subscriptions are scheduled payments to pay for products or services that occurs frequently. For example, a cardholder paying for an on-demand internet service provider’s monthly subscription fee without having to manually pay every month. After first successful payment from the customers card, the card is stored as a token which will be used for subsequent transactions.
Note that recurrent transaction works only for cards
Ideal for: Charging a customer on a schedule — monthly software, membership dues, instalment plans. The customer authorises once, and SeerBit charges the stored card thereafter.
Note: Recurring transactions work with cards only. After the first successful payment the card is stored as a token, and subsequent charges use that token.

Subscriptions or card tokenisation?

Both charge a card the customer has already authorised, but they differ in who decides when the charge happens. Use a subscription when the billing is regular and predictable. Use tokenisation when you need to charge a saved card at unpredictable times or for varying amounts.

How it works

1

Create a plan

Define the amount, currency and billing cycle once. A plan is the template every subscriber is billed against.
2

Subscribe a customer

The customer makes a first payment against the plan. That payment authorises the card and returns an authorizationCode.
3

SeerBit charges on schedule

Subsequent charges happen automatically on the plan’s cycle, using the stored token.
4

Manage the subscription

Look subscriptions up by customer, update them, or charge the stored card yourself with the authorizationCode.
You can also create plans without code on the SeerBit merchant dashboard.

Authentication

Subscription calls are authenticated with a bearer token, generated from your public and secret keys — the same as every other collection API.

Authentication

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

Create Plan

For the full specification, see our API Reference POST

Request Sample

The code snippet below shows an example request for creating a subscription
Billing Cycle should be set to : DAILY, WEEKLY, MONTHLY or ANNUALLY
Response Sample
The code snippet below shows an example response for creating a subscription

Parameter description

Get Merchant Subscription

The Get Merchant Subscription returns all customer subscriptions. Included in the response is authorizationCode which can be used for separate charges to the customer For the full specification, see our API Reference GET

Request Sample

Response Sample

The code snippet below shows an example response to get merchant subscription

Charge Subscription

For the full specification, see our API Reference POST

Request Sample

The code snippet below shows an example request for charging a customer with an authorizationCode
Authorise Charge - Authorisation Code is gotten when a subscription has been successfully completed
Response Sample
The code snippet below shows an example response for charging a subscription

Parameter description

Get Customer Subscription

For the full specification, see our API Reference GET

Request Sample

Response Sample
The code snippet below shows an example response to get customer subscription by customerId

Update Customer Subscription

For the full specification, see our API Reference PUT

Request Sample

The code snippet below shows an example request for updating a subscription
For credit cards you can update the previously stored payment details, this may be required when the card expiry date or the billing/delivery address changes.
Response Sample
The code snippet below shows an example response for updating a subscription

Notes

  • Store the authorizationCode. It is what lets you charge the saved card again — without it you must ask the customer to authorise afresh.
  • limit ends the subscription. Set it to the number of cycles you intend to bill; leaving it open means charging until the subscription is cancelled.
  • Cards only. Bank transfer, USSD and mobile money cannot be used for recurring charges, so offer a card at sign-up even if your checkout supports other methods.
  • A failed cycle is not a cancelled subscription. Watch for the recurring-debit webhook events and handle a decline in your own dunning logic.
  • Confirm every charge server-side before granting access — see Verify a payment.