Note that recurrent transaction works only for cardsIdeal 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.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 POSTRequest Sample
The code snippet below shows an example request for creating a subscriptionBilling Cycle should be set to : DAILY, WEEKLY, MONTHLY or ANNUALLY
Response Sample
The code snippet below shows an example response for creating a subscriptionParameter 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 GETRequest Sample
Response Sample
The code snippet below shows an example response to get merchant subscriptionCharge Subscription
For the full specification, see our API Reference POSTRequest Sample
The code snippet below shows an example request for charging a customer with an authorizationCodeAuthorise 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 subscriptionParameter description
Get Customer Subscription
For the full specification, see our API Reference GETRequest Sample
Response Sample
The code snippet below shows an example response to get customer subscription by customerIdUpdate Customer Subscription
For the full specification, see our API Reference PUTRequest Sample
The code snippet below shows an example request for updating a subscriptionFor 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 subscriptionNotes
- Store the
authorizationCode. It is what lets you charge the saved card again — without it you must ask the customer to authorise afresh. limitends 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.