Testing
Overview
When integrating a payment gateway, you must test your implementation before going live. We've got test card and bank account (for debit orders)details for you to use when testing. The cards cover a variety of use cases and allow you to simulate successful and failed transactions with different causes.
Speak with your Account manager to test alternative payment methods like Instant EFT, Mobile money, etc.
Card payment testing
| Payment success | Card details |
|---|---|
| 3d secure | 5555 5555 5555 4444 |
| non 3d secure | 4444 3333 2222 1111 |
For both cards, please use:
- any cardholder name
- any expiry larger or equal to the current month/year
- CVC = 123
- For a failed payment, please change the CVC or expiration date.
- Using a wrong expiry date emulates data validation failure and results in immediate error .
| Payment failure | Card details |
|---|---|
| 3d secure | Incorrect CVC will trigger an authorisation failure on the S2S callback step. Using a wrong expiry date emulates data validation failure and results in immediate error before that step |
| non 3d secure | Incorrect CVC will trigger an authorisation failure |
Debit order and DebiCheck testing
Revio's mock-bank infrastructure allows you to test mandate creation, collections, and payments as if executing them in a live environment. This includes status changes and industry business rules. The following scenarios can be tested with the mock-bank interface:
| Instrument | Scenarios |
|---|---|
| EFT debit order (single and bulk) | Create mandate |
| Amend mandate | |
| Create collection | |
| DebiCheck (single and bulk) | Create mandate (TT1/TT2) |
| Amend mandate | |
| Cancel/suspend mandate | |
| Create collection |
You can force the simulation of collection results as follows:
- To get a full reject Debicheck response file, provide the account number: '910000001' as one of the account numbers in the transactions.
- To get a batch rejection Debicheck response file, provide the account number: '910000002' as one of the account numbers in the transactions.
- To get a dispute file 40 seconds after response file, provide the account number: '210000001' as one of the account numbers in the transactions.
- To get an accepted file 40 seconds after a pending response file, provide the account number: '110000001' as one of the account numbers in the transactions.
- To get an unpaid file 40 seconds after a pending response file, provide the account number: '110000002' as one of the account numbers in the transactions.
- To get an accepted file with a Bankserv settlement date 3 days from today 40 seconds after a pending response file, provide the account number: '110000003' as one of the account numbers in the transactions.
- To get an unpaid file with a Bankserv settlement date 3 days from today 40 seconds after a pending response file, provide the account number: '110000004' as one of the account numbers in the transactions.
- To get an accepted file with a Bankserv settlement date 5 days from today 40 seconds after a pending response file, provide the account number: '110000005' as one of the account numbers in the transactions.
- To get an unpaid file with a Bankserv settlement date 5 days from today 40 seconds after a pending response file, provide the account number: '110000006' as one of the account numbers in the transactions.
- All other account numbers will result in accepted responses.
See the Mandate management section for DebiCheck mandate creation test cases.
Debit order and Debicheck test configuration
General merchant credentials
| Test detail | Description |
|---|---|
| Profile code | "TEST1" |
| Abbreviated name | "TESTMERCH1" |
| Creditor or clearing account number | "12345678 |
Debicheck specific configuration
DebiCheck mandates include several essential fields that must be customised based on your specific use case. Among these fields, the value_type is particularly critical as it determines the rule set governing the processing of collections. Here are the available value_type options and their characteristics:
| Field | Description |
|---|---|
| FIXED | With this value_type, no adjustments to the amount or rate are allowed. The products.price and max_amount_cents remain constant throughout the mandate. The max_amount_cents is limited to the products.price |
| VARIABLE | Despite the name, this value_type does allow for adjustments in the amount and rate of collections. You can collect amounts different from the authenticated products.price, but within the limit of the max_amount_cents. However, such collections are disputable. The max_amount_cents is limited to 1.5 times the products.price |
| USAGEBASED | This value_type permits adjustments in the collection amount and rate. Like "VARIABLE", you can collect amounts other than the authenticated products.price, but within the max_amount_cents limit. Again, these collections are disputable. The max_amount_cents has no specific limit, but it's advisable to exercise caution when using large values to ensure a smooth customer experience |
Note that you should not enable both adjustment_rate and adjustment_amount_cents. Choose one, omit the other from your payload or provide it as null.
Below are descriptions of the other important fields related to DebiCheck mandates:
| Field name | Type | Description |
|---|---|---|
| authentication_type | string | Determines whether the authentication is sent in real-time (TT1) or delayed (TT2). REALTIME initiates a USSD/push notification for acceptance within 120 seconds, while DELAYED sends an SMS for acceptance within 48 hours. |
| do_delayed_auth_on_failure | boolean | When enabled, this field triggers a TT2 authentication with a 48-hour response time to obtain authentication when real-time authentication is unavailable or fails. You can also consult with us about enabling RMS when TT1 or TT2 requests time-out. |
| debit_sequence | string | Determines whether the mandate is for a one-time collection or recurring collections. |
| adjustment_category | string | Determines the frequency of adjustments made to the products.price and max_amount_cents over time based on the DebiCheck rules and adjustment_rate or adjustment_amount_cents used. You can specify the relevant adjustment frequency, such as quarterly, biannually, annually, etc. |
| allow_date_adjustment | boolean | When enabled, it allows for the variation of the due_date of recurring charges to a date different from what was initially authenticated. Adjusting the date to any other than the authenticated date makes the collection disputable. |
By understanding and configuring these fields, you can tailor the DebiCheck mandates to your specific requirements and ensure compliance with industry rules and regulations.
Please get in touch with support at [email protected] to activate the mock-bank feature for you. Once activated, please make use of your Live API keys to test.
Testing tip
Access this link to create test SA ID Numbers
Updated 3 months ago