Skip to main content
A payment is collected in five steps:
  1. Create a payment intent (PaymentIntent).
  2. Attempt a payment on it.
  3. (Optional) On the client side, authenticate the payment attempt.
  4. HUB2 processes the payment with the provider.
  5. Retrieve the status of the PaymentIntent.

Create a payment intent

The PaymentIntent object represents the intent to collect a payment from a customer. It keeps track of the fees and of every payment attempt made during processing. The PaymentIntent must be created on the merchant server with an amount, a currency, a customer reference (customerReference) and a purchase reference (purchaseReference). Create a payment intent Sample request:
Store the id and the token returned in the response on the merchant side: the next steps require them.
  • The id is the unique reference of the PaymentIntent. It is used to attempt payments.
  • The token is a JSON Web Token (JWT) that authenticates the payment requests. It expires 30 minutes after the PaymentIntent is created: a payment attempt or an authentication sent with an expired token is refused with a 401 error (bad_payment_intent_token).

Attempt a payment on the payment intent

Once the PaymentIntent is created, collect the payment information from the end customer and attempt a Payment. To attempt a Payment, specify the paymentMethod and every required field described in the API reference. Attempt a payment This endpoint accepts the JWT token instead of your private API key, so the payment request can be sent directly from the client side (by the customer’s application), using the token retrieved previously.
If the request succeeds, the API returns HTTP 201 with the full PaymentIntent object in the response body. The status is now processing and the payments array contains the new Payment attempt. Save the payment id to identify this attempt in the list: several payments can be attempted on one PaymentIntent.

Retrieve Payment status

After the payment attempt, HUB2 contacts the payment provider and updates the payment object according to its response. From this point, the payment status can be retrieved in two ways. Use webhooks rather than polling the PaymentIntent for status updates. See Webhooks integration to implement them. Subscribe to the payment.* or payment_intent.* events. With this method, the merchant server is notified as soon as the Payment or the PaymentIntent is updated. No polling mechanism is needed, no rate limit applies and latency issues are avoided. Under high payment traffic, it also reduces the load on both the merchant servers and the HUB2 servers.

2. Status polling

Poll the payment status with the dedicated endpoint. Retrieve the status payment object
This endpoint is rate limited (5 requests per 5 seconds for a given payment) to prevent denial-of-service attacks. Beyond that limit, the API returns HTTP 429 - Too Many Requests. Take this into account when implementing status polling.
Sample request:
This request returns the status of a payment. A separate endpoint returns the status of a payment intent. Retrieve a payment intent status

Important

Poll only while PaymentIntent.status is processing or action_required. Continuously polling a PaymentIntent whose status is payment_required, successful, failed or canceled will get the source IP address throttled or temporarily banned.
In most cases, the next PaymentIntent status is action_required. This status means that the customer must perform a manual action to authenticate or validate the payment.

Handle the customer action

The Payment object contains a nextAction object that describes the action required from the customer.

Important

The relevant part is: "nextAction": { "type": "otp", "message": "Sandbox mode. Type a 4-digit number to authenticate the payment." }.
Display nextAction.message to the end customer so they know how to validate the payment. The action type is one of:
  • redirection: provides everything needed to redirect the customer to an external page.
  • ussd: tells the customer which USSD procedure to follow to validate the payment.
  • otp: tells the customer how to generate a one-time password (OTP). The customer enters the OTP in a field, and you send it to the dedicated endpoint. Some providers accept the OTP directly in the payment attempt request (see the otp field of the mobileMoney object).

Bank collection

The bank collection feature lets a merchant offer customers a bank transfer payment option. The customer receives a unique reference to make the transfer.

Prerequisites

This payment method requires a prior KYB (Know Your Business) registration. Create a KYB registration

Payment process

  1. The merchant creates a payment intent (PaymentIntent) as described above.
  2. For the payment attempt, the merchant sets bank_transfer as the payment method and provides the bankTransfer object:
    • kybName (required): the name declared in the KYB registration.
    • expirationDelay (optional): number of seconds before the payment expires. Minimum 3600, default 1296000 (15 days).
  3. HUB2 generates a unique reference for the transfer.
  4. The customer receives this reference and makes the transfer.
  5. The payment status is updated once the transfer is received. If no transfer is received before the expiration delay, the payment fails with the expired failure cause.
Attempt a payment

API response

On success, the API returns a PaymentIntent object containing the bank transfer payment details, including the unique reference generated for the transfer.
Important: communicate the reference to the end customer so they can make the bank transfer. The payment status is updated once the transfer is received and processed.