4.1. FAQ

4.1.1. Gather useful information

Here is a list of useful information that might be mentioned in your report to help us to find your problem requests during the integration:

  • Indicate either you are using sandbox or production environment.
  • The fastest way to find your request is using serial-number but sometimes this is not possible to get this identifier. In such cases you should provide us client_orderid, ENDPOINTID (or ENDPOINTGROUPID) and estimated time of the initial request.
  • Indicate whether or not the functionality worked at one time or not. If so, indicate since when it stopped working.
  • Add relevant log information when any is available. If you have to paste a lot of text, is it preferred to save it as a file on your computer and attach it to your report.

4.1.2. Frequently asked questions during the integration

These simple instructions will help you to resolve incorrect control code calculation

The calculation of the control code may be different for different types of API calls. The most common errors are:
- wrong credentials, check credentials received from your account manager,
- API calls have been sent to production environment instead of sandbox,
- either you are using wrong ENDPOINTID or you're not passing it at all,
- you are using ENDPOINTID URL with ENDPOINTGROUPID or vise versa,
- you might be using production account settings on sandbox or vise versa,
- you might be using production control key on sandbox and or vise versa,
- signing parameters are in incorrect order,
- the amount of the transaction is not converted to minimal decimal units.

The best way to check control code calculation is to use the DEBUG sections in API documentation:
- first of all choose the correct URL from the combobox with API calls selection, if any,
- after it check that fields marked as red contain the correct values, the same as yours. All of them are used to calculate the signature,
- after pressing the Sign button check values for the String to sign whether you are signing the same string or not,
- if the signing string looks correct your signature must be the same as the signature in Signature field,
- finally try to login into your merchant portal and go to Tools -> Integration Panel, and find your request in the panel. If you are getting an error INVALID_CONTROL_CODE from our gateway, your request ought to be found by serial-number from the same answer. If you can not find your request, check the most common errors above, looks like you're using the wrong credentials

What is the difference and can one be used instead of another

Apropay gateway supports any currency, but this support has some limitations. If you received ENDPOINTID - your project have been configured to process transactions in a single currency. To work with multiple currencies your account manager will create you as many ENDPOINTIDs as many currencies do you need to handle. If you do not want to manage this process in your backoffice - you can ask him to provide you the unified point of integration for all the currencies you want to use. In this case you will receive ENDPOINTGROUPID. So in general
- ENDPOINTID supports only one currency
- ENDPOINTGROUPID supports as many currencies as you need, but you need to send the full list to your account manager, so he can configure the project settings for you.
Due to the different nature of these two entities it is impossible to use ENDPOINTID instead of ENDPOINTGROUPID and vise versa.

Apropay gateway is using asynchronous API

If you are going to use synchronous API you need to implement it on your side. For some API calls we are providing Synchronous API. Ask your manager to refine if it is possible to make synchronous calls in your case.

Even in native app you should use embedded WebView component to open banking ACS server url

To pass the transactions without 3-D Secure your application must meet the following requirements:
- your customer is identified and there is a low fraud probability, it this case you can ask your account manager to open you non-3DS account,
- you have PCI DSS certificate and can gather cardholder data on your side, in this case you can ask your account manager to open you account with Direct API support to avoid unnecessary redirects.

This is your number of the transaction you can generate it on your own

.

For e-commerce transactions we are using different CVVs

For different types of API we have different mechanisms for getting approved transactions and transactions in other statuses. For e-commerce transactions this information could be found in public access E-Commerce test cards. For card present transactions (EMV and MSR) you can use different transaction amounts to get different results:
- 1.00, APPROVED (Purchase, Final Advice),
- 2.00, DECLINED (Purchase),
- 3.00, APPROVED (Purchase),
- 4.00, DECLINED (Purchase, Final Advice).
You can use any card for testing card present transactions. POS terminal is always asking a card to use ARQC. The card is asked to perform online authorisation. Apropay gateway is answering Authorisation Response Code = 'Z3' (Unable to go online, offline declined), this answer is transferred to card for Final Advice amounts, otherwise we are making a decision that the answer from card is TC or AAC to the first GEN AC, and finishing the transaction.
To get information for other APIs please contact your account manager.

Yes they are, this is not a BUG

To improve readability of the answer we are adding (0xA) character at the end of each parameters value. To process the answer from the server you need need to ignore this character.

No, you are not

All the parameters for the final redirect are passed thru the clients browser. They can be lost during the transmission over the internet. To get guaranteed result from Apropay gateway use server_callback_url parameter.

No, you are not

Transmitting parameters using HTTP GET is strictly forbidden to avoid possible data leaks.

You need to use full URL with http:// or https://

For example you need to pass http://www.google.com or https://www.google.com instead of www.google.com. Only following ports are allowed
- 80, 8080 for HTTP
- 443, 8443 for HTTPS

The best idea is using callbacks, but the normal polling interval is 3 seconds

Payment Status query is recommended to be used once in a three seconds. Normally it takes aquirer up to 3 seconds to process the transaction. The total time of polling the transaction status should not be longer then 1 hour even for 3-D Secure transactions. If your acquirer processes transactions in offline mode you must implement callback processing in your backend. For other polling intervals (below 3 seconds) please notify your account manager, otherwise you could be banned for aggressive polling policy.

You need to use urldecode to process html parameter in Apropay gateway response

We are trying to help our merchants to integrate our environment in a correct way. This test gives you an ability to check, if the bank response will be processed correctly on production environment. If you are getting this error, you aren't using urldecode to parse the Apropay gateway response or it works in incorrect way (for example in some versions of PHP you need to use rawurldecode instread).