- Manage your aliases (live mode only).
- Collect an instant payment.
- Send an instant payment.
Manage your aliases
HUB2 API reference - List aliases HUB2 API reference - Create an alias HUB2 API reference - Delete an alias The three alias endpoints address one of your accounts through theaccountType path parameter: collection (receives instant payments) or transfer (pays them out). They only work in live mode: in sandbox they are refused with a 403 error (instant_payment_live_only).
List the aliases of an account
The list contains every alias the directory holds for the account, including the primary alias registered by HUB2.Curl
aliasKey is the value to publish so that payers can reach your account, and the value to send as payeeAlias when you attempt a payment.
Create an alias
Curl
SHID key. An account holds one SHID alias, so when the account already has one, the API responds with 201 and returns that alias with created set to false instead of creating a second one. Retrying a creation is therefore always safe.
Delete an alias
Curl
204 No Content. From then on, payers can no longer reach your account through this alias and HUB2 no longer accepts it as your own alias on a payment.
- The primary alias registered by HUB2 cannot be deleted: the request is refused with a
409error (instant_payment_primary_alias_protected). Contact HUB2 Support to retire it. - An alias that is not yours is refused exactly like an alias that does not exist, with a
403error (instant_payment_alias_not_owned).
Alias errors
Collect an instant payment
A collection follows the payment integration: you create a payment intent, attempt a payment on it, then follow its status. Only the payment attempt differs for instant payment. The payment intent must be inXOF.
Get the fees
HUB2 API reference - Retrieve fees To display the fees before the customer pays, call the fees endpoint of the payment intent withpaymentMethod=instant_payment and the country. The provider parameter is not required for instant payment, which has a single provider. If you send it, it is ignored.
Curl
Attempt the payment
HUB2 API reference - Attempt a payment Attempt a payment on the payment intent with the payment methodinstant_payment.
Curl
There is no
provider field and no mobileMoney object. Both aliases are stated on every request and are never trimmed or normalized: send them exactly as stored.
HUB2 checks everything it can before the request reaches the rail, because a payment sent on the rail cannot be recalled:
- the country is served, and instant payment is enabled for your merchant account;
payeeAliasis well formed and is one of your active collection aliases. An alias registered to another merchant, or to nobody, is refused in the same way (403,instant_payment_alias_not_owned);payerAliasis well formed. HUB2 does not check that it exists: the rail answers that, and a payer alias that does not exist makes the payment fail.
Follow the payment
The payment is created increated status, then stays pending while the rail processes it, and the payment intent is processing. The outcome comes from the rail and updates the payment to successful or failed, with a failure object that holds the failure cause.
Use webhooks to follow the outcome, as for any other payment method. If you cannot, poll the payment intent status only while the status is processing.
When HUB2 cannot tell whether the rail received a request, the payment stays pending instead of being failed. Do not create a second payment for the same purchase in that case: wait for the webhook or read the status.
Payment errors
Send an instant payment
HUB2 API reference - Create a transfer A transfer follows the transfer integration. For instant payment, set the destination type toinstant_payment and send the alias of the beneficiary. The currency must be XOF.
Curl
There is no payer alias in the request. The account debited is always your own transfer account, and HUB2 selects the alias to use among the aliases registered on it, the primary one first. The response returns the
payerAlias used and the payeeAlias you sent in the destination object, together with provider set to pispi.
If your transfer account has no active alias, the transfer is refused with a 400 error. As for a payment, HUB2 only checks the shape of the beneficiary’s alias: a beneficiary alias that does not exist makes the transfer fail.
A transfer goes through the usual statuses (created, pending, then successful or failed). Follow it with webhooks, as for the other destinations. When HUB2 cannot tell whether the rail received the request, the transfer stays pending: do not create a second transfer for the same beneficiary, wait for the webhook or read the status.
Transfer errors
Failure causes
When a payment or a transfer fails, thefailure.code field gives the cause. The failure causes of the rail are translated as follows:
See also the complete lists of payment failure causes and transfer failure causes.
Sandbox
In sandbox mode, no request reaches the rail: HUB2 simulates the outcome from the last 8 characters of the counterparty alias, which is thepayerAlias of a payment and the payeeAlias of a transfer. The alias must still be well formed, for example +22500000001, and the country must be CI or SN.
Your own aliases are still checked in sandbox: the payeeAlias of a payment must be a collection alias of your merchant account, and a transfer needs an alias on your transfer account. Aliases cannot be created in sandbox, so list them beforehand in live mode (see Manage your aliases) and reuse them in sandbox.
Payments
Any other value makes the payment fail with
bad_parameters.
Transfers
Any other value makes the transfer fail with
invalid_destination.