Integration and Certification Stages
The integration and certification process consists of the following stages:
- Integration. Once registered, clients learn our exchange protocol and are able to simulate real processing using our integration environment system. The time period is not limited but usually takes about 7 – 10 days.
- Certification. Once familiar with our API, merchants should contact our merchant support to schedule a certification date. The certification time slot is 48 hours, which may be extended upon request. Clients will be required to perform a specific set of certification tests customised according to the scope. Please note that at the time of certification the profile will be frozen to prevent any changes, so you should complete your profile entry prior to certification starting.
Certification Procedure
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.
[a1] “Request ID” Parameter Usage
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.
[d2] “Echo” Parameter Usage
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.
Request Parameter Validation
To assist with request parameter validation, we have deployed a simple tool at
https://intconsole.credorax.com/console/debug/ShowRequest.jsp
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.
Credorax integration support
You can reach customer support at integration[at]credorax.com.