The customer did a bank transfer but did not include the reference
Failure to include this reference will result in EMS refunding the money to the customer. He or she will have to initiate another bank transfer. No status update via the webhook will be done when this occurs
Posting the incorrect API key
Each request is authenticated with the encoded base64 authentication token. Please refer to the Authentication section. The incorrect authentication token will result in response with an error. Performing such a request is illustrated in the example bellow.
If we misspell the authentication token and you try to send the encoded
hutter2
in base64:
Request:
GET /v1/orders/4c6afd74-a840-4aab-b411-1e6e0636d341/ HTTP/1.1
Authorization: Basic aHV0dGVyMgo=
Response:
{
"error": {
"type": "<class 'werkzeug.exceptions.Unauthorized'>",
"value": "The server could not verify that you are authorized to access the URL requested. You either supplied the wrong credentials (e.g. a bad password), or your browser doesn't understand how to supply the credentials required."
}
}
Unsupported payment method
A merchant should apply for each of the provided methods separately. When the merchant is verified and the payment method is activated, the merchant can provide the payment method to the customers. If the payment method is not activated or the order request demands the unsupported payment method the server will respond with an error. It will also include the reson of the error.
An example below simulates an order request with the inactive credit-card
payment method credit-card
. The server responds with the error
status for such order request. The response also provides the reason
, which describes the error in detail.
Request:
POST /v1/orders/ HTTP/1.1
Authorization: Basic __AUTH_BASE64_KEY__
Content-Type: application/json
{
"merchant_order_id": "EXAMPLE001",
"amount": 995,
"currency": "EUR",
"description": "Example order #1",
"return_url": "http://www.example.com/",
"transactions": [
{
"payment_method": "credit-card"
}
]
}
Response:
{
"error": {
"type": "<class 'werkzeug.exceptions.BadRequest'>",
"value": "The browser (or proxy) sent a request that this server could not understand."
}
}
Sandbox test card numbers
Card type | PAN number | Expiration | CVC/CVV | 3D secure Passcode |
---|---|---|---|---|
VISA #1 | 4012 0010 3714 1112 | 06/2025 | 123 | test123 |
VISA #2 | 4035 8740 0042 4977 | 12/2025 | 123 | n/a |
MasterCard #1 | 5453 0100 0007 0789 | 12/2020 | 977 | Secret!33 |
MasterCard #2 | 5426 0640 0042 4979 | 12/2024 | 979 | Secret!33 |
Please note that if you have tested with these cards, the implementation will also work for Maestro, V PAY, Bancontact & Diners / Discover.
Sandbox iDEAL test cases
Amount | Case name | Description |
---|---|---|
100 | Success | Submission of a transaction with an amount of € 1,00 will return a ‘Success’ status. |
200 | Cancelled | Submission of a transaction with an amount of € 2,00 will return a ‘Cancelled’ status. |
300 | Expired | Submission of a transaction with an amount of € 3,00 will return an ‘Expired’ status. |
400 | Open | Submission of a transaction with an amount of € 4,00 will return an ‘Open’ status. The end status is not yet known. |
500 | Failure | Submission of a transaction with an amount of € 5,00 will return a ‘Failure’ status. |
Directory Request | A correct Directory Request must be submitted. | |
700 | Syntax error | Submission of a transaction with an amount of € 7,00 will return an ‘SO1000’ error message. |
Webhook retries
When the webhook call is unsuccessful it is retried. More on this can be found in the webhooks documentation.
How to test Payconiq
You need the Payconiq EXT app to do a Payconiq test transaction. Access to the app can be requested by sending an e-mail to devsupport@payconiq.com.