The integration and certification process consists of the following stages:
The whole set of certification test are designed to check the merchant system’s ability to perform the operations defined by the API in various scenarios, including some error cases.
A merchant is required to perform a specific set of certification tests customised according to the given merchant’s scope. Each of the gateway operations selected will be supported by one or more tests. These tests should reflect production transaction scenarios. They include typical sale and refund transactions in both success and failure scenarios.
Figure 1. shows an example of a certification test. Each test comes with a set of default parameter values. These values are given in their real world format (e.g. “+1(555)123-4567” or “Apartment #101”), and it’s the job of the merchant to match them to the appropriate API fields and clean up the data to comply with format restrictions (in the example above, the phone number would become “c2=1-555-123-4567” or “c2=15551234567” in the request, while the apartment number should be sent as “c6=101”).
Please note that while performing these tests, absolutely all required fields have to be populated, unless a special clause in a specific test case schedule is provided.
The “[d2] Echo” is unique for every test and should be copied exactly, since it is used as a test identifier.
Finally, the last transaction containing the test ID affects the certification status. For example, if you send a transaction that passes a test, and then submit another API request that fails it (a common mistake is using the same “[a1] Request Id”), then the test would be marked as “failed”. In order to change its state back to “passed” you’d have to submit a new transaction that would satisfy the gateway again.
Certainly, the best way to approach the certification is to use the real production system the merchant has in place.
The request ID parameter is expected to be unique for every transaction posted by the given merchant. However, during integration and certification the request ID space can be shared between multiple accounts. To ensure uniqueness, you can prepend the “a1” parameter with a numeric prefix (e.g. your merchant ID). This should be sufficient to create unique transactions during integration and certification.
During integration testing, use the [d2] “Echo” parameter to transaction approval. A non-empty value (any value) triggers an APROVED response from the gateway (given no other errors are found), while an empty value would cause your transaction to be rejected.
When certification testing is in progress, the [d2] parameter carries a unique test code, which allows the system to identify which test are you currently working on. This makes the [d2] mandatory during the certification.
To assist with request parameter validation, we have deployed a simple tool at
You can use the above URL instead of the CredoRax Gateway URL. It shows all parameter values in a neatly formatted grid, which could be helpful for debugging gateway requests.
You can reach customer support at integration[at]credorax.com.