We are working on exciting features. While we work, keep building!
We added the Pay with Transfer (PwT) channel to the Create ChargeAPI endpoint. You can now tie an account number to a transaction for a limited period, allowing your customers to complete a transaction from their banking apps. The changes made are:
We added a
bank.transfer.rejectedevent which is sent when a customer sends an incorrect amount or when the customer has been flagged by our fraud system
We now return transfer references for bulk transfers. Previously, the response of the Bulk TransferAPI request didn't come with either your custom or our generated
reference. We've fixed this, making it easier for you to track your transfers.
In order to remain compliant with our product offerings, we sunsetted one of our legacy integration rails that has no support for 3DS 2.0. The check authorization endpoint is powered by this rail and as a result, we deprecated the endpoint.
We now make use of an unsigned 64-bit integer to represent transaction IDs. Merchants who store or make use of the transaction IDs need to ensure it is represented as an unsigned 64-bit integer. Here are some recommendations for some common tech stacks:
|Tech Stack||Data Type||Reference|
|MySQL||unsigned bigint||MySQL doc|
|C#||unsigned long||Microsoft doc|
|C/C++||unsigned long long||Microsoft doc|
We also made some changes to the Customer ValidationAPI:
We added a
reasonparameter to the
customeridentification.failedwebhook event. Merchants can use this parameter to find out the cause of a failed customer validation.
middle_nameas an optional parameter to the Customer ValidationAPI. You can add this as an extra parameter when validating a customer's details.
We added an endpoint to Requery Dedicated Virtual AccountsAPI. Merchants can use this endpoint to check a virtual account for new transactions that haven't been processed yet. Calling this endpoint will trigger a background requery process, and if any pending transactions are found, the transaction will be created, and the webhook notification will be sent to your server.
phone to the request body of the Create Dedicated Virtual AccountAPI. Merchants can use these parameters to update an existing customer's record and create a dedicated virtual account in one API call.
We updated the statuses of refunds to better capture the state of a refund:
pending: The refund initiated, waiting for response from the processor.
processing: The refund has been received by the processor.
processed: The refund has successfully been processed by the processor.
failed: The refund cannot be processed. Your account is credited with refund amount.
When a refund is initiated for a transaction, the transaction's status previously showed
reversed regardless of whether the refund had been processed. We're now better reflecting the status of a transaction with the following:
reversal pending: The refund is pending or still processing.
reversed: The refund has been successfully processed.
success: The refund failed and your account is credited with the refund amount.
We now send webhook events to monitor the state of a refund:
Check out the Refunds documentation to learn more about refunds and how to automate your refunds.
We added three new statuses to the SubscriptionAPI:
non-renewing: The subscription is still active but won't be charged on the next payment date and will be marked as completed.
attention: The subscription is still active, but there was an issue while trying to charge the customer's card. The issue can be an expired card, insufficient funds, etc. We'll attempt charging the card again on the next payment date.
cancelled: The subscription has been cancelled.
Check the list of subscriptions statuses to learn more.
We deprecated support for BVN type on the Customer ValidationAPI. Going forward, we advise against using the
type: "bvn" and
value parameter in the request body in favour of Bank Account validation for existing and new customers.