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:


GET /v1/orders/4c6afd74-a840-4aab-b411-1e6e0636d341/ HTTP/1.1
Authorization: Basic aHV0dGVyMgo=


     "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.


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": "",
  "transactions": [
         "payment_method": "credit-card"


     "error": {
       "type": "<class 'werkzeug.exceptions.BadRequest'>", 
    "value": "The browser (or proxy) sent a request that this server could not understand."
Change email address PayPal
Change email address PayPal

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