Absa Pay Integration Process
No integration changes are required to include Absa Pay.
Additional optional payment request fields
The following optional fields can be passed in for the Absa Pay flow:
| Request Field | Description | Type |
|---|---|---|
| enabled | By default, the Absa Pay payment method is enabled for all payment requests. Use this optional field to disable Absa Pay at the payment request level, replacing it with the Absa iEFT implementation. | Boolean |
| payerDisplayNarrative | This is the description of the goods or services that the user is purchasing. This is defaulted to {payee_name} payment. | String |
| merchantDetails.name | This is used to customise the payee name field which is shown on the approval prompt in the Absa application. This is defaulted to the configured client name. | String |
Within the payment request mutation, this looks as follows:
Implementing the Verified Flow
Should Absa require that you implement the "Verified flow", you will need to include the payer's verified identifier when creating a payment request.
A payer's South African Identity Number must be used as a verified identifier. If a value is provided, it will only be validated when paying with Absa Pay.
The identityNumber must be a valid South African Identity Number.
If an invalid South African Identity Number is provided, the Absa Pay payment initiation request will fail with a message indicating that a valid South African ID number is required.
Within the payment request mutation, initiating the verified flow on Absa Pay is as follows:
Unverified users
If the user selects Absa Pay from the list of banks while attempting to make their payment, and the identifier passed in the above
mutations is either invalid, missing, or is not associated with a Absa bank account they will be presented with a message indicating
that they need to verify their details before being redirected back to your site with reason=verification_required.
Testing Absa Pay Scenarios
Our sandbox environment allows simulation of specific Absa Pay scenarios that users may experience in production, including how a user could handle MFA (multi-factor authentication) in their Absa app. To simulate these cases, the beneficiaryReference of your payment request can be tweaked as follows:
| Scenario | Beneficiary Reference |
|---|---|
| MFA successful and payment completed for user with single account | success |
| MFA successful and payment completed for user with multiple accounts | success-multiple |
| MFA request timed out | success-timeout |
| MFA request declined by user | success-declined |
| Insufficient funds | success-insufficient |
| Daily limit exceeded | success-dailyLimit |
| MFA successful, but payment fails | success-paymentFail |
| Payment initiation failure at Absa | failed |
| Payment intiated from an account without an Absa application | notADigitalCustomer |
| Payment intiated from non-existent Absa account | noAccountFound |
| Payment intiated for a beneficiary that has already been paid | paidBeneficiary |
| Payment intiated from a business account that cannot initiate Absa Pay payments | invalidBusinessAcc |
| Duplicate payment intiated | duplicatePayment |