Troubleshooting: Difference between revisions
| Line 12: | Line 12: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Calling GetPaymentState only when the customer is redirected to the shop | |Calling GetPaymentState only when the customer is redirected to the shop | ||
|This approach only works if the customer actually returns to the shop. If the user closes the browser after payment, but before returning to the shop, the merchant will not get notified about the successful payment. As a result, some developers choose to poll the server periodically. | |This approach only works if the customer actually returns to the shop. If the user closes the browser after payment, but before returning to the shop, the merchant will not get notified about the successful payment. As a result, some developers choose to poll the server periodically. We strongly recommend using the callback. | ||
|- | |- | ||
|Polling the server with GetPaymentState calls | |Polling the server with GetPaymentState calls | ||
|This approach floods the Barion servers with unnecessary API calls, which, if excessive, may lead to rejection of the shop. It is also more complex to code and to test. | |This approach floods the Barion servers with unnecessary API calls, which, if excessive, may lead to rejection of the shop. It is also more complex to code and to test. We strongly recommend using the callback. | ||
|} | |} | ||
Revision as of 12:08, 6 February 2017
Troubleshooting - list of common pitfalls
Before contacting support, please run through the list of common pitfalls. This will save both you and us a lot of time. Here we go with the list.
Use the callback
Many developers fail to implement the callback mechanism. Instead, they either rely on on of the following faulty strategies:
| Calling GetPaymentState only when the customer is redirected to the shop | This approach only works if the customer actually returns to the shop. If the user closes the browser after payment, but before returning to the shop, the merchant will not get notified about the successful payment. As a result, some developers choose to poll the server periodically. We strongly recommend using the callback. |
| Polling the server with GetPaymentState calls | This approach floods the Barion servers with unnecessary API calls, which, if excessive, may lead to rejection of the shop. It is also more complex to code and to test. We strongly recommend using the callback. |
Always rely on the callback. The Barion server retries the callback 5 times, so the chances of losing a payment is very little.
Mixing up sandbox and live accounts
It is very easy to mix up Live and Sandbox environments. Since the two systems are totally separated, you can have an account with the same e-mail address in both systems. Double check, if you can not log on.
Forgot to update POSKey to live
It is very easy to mix up Live and Sandbox environments. A very common mistake is to not update the POSKey to the Live server when going live. Same goes to URL-s.
Shop not approved
Log on to Barion Web App and check if your shop is approved and open. The Sandbox server does it automatically, but the Live requires human approval.
Authentication error upon request
If you have managed to avoid all problems mentioned above, yet you still receive an API response showing 'Authentication error', check your request JSON for errors. Broken multibyte strings or unescaped special characters can render the JSON unparseable, which prevents the Barion API from identifying your POSKey, resulting in an authentication error.