You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The MID

By subscribing to Axepta, you will have access to one or several MID. A MID or Merchant ID allows you to identify an online store.

There are 3 types of MIDs:

  • MasterMID: Allows you to have a global view of the activity of the merchant on the different shops he owns. The masterMID cannot be used to perform transactions but is mainly used to connect to the backoffice and visualize its entire activity.
  • Test MID: Allows you to perform test transactions (without having to bank).
  • Production MID: Allows transactions to be carried out in a production environment (LIVE environment, with banking).


The production transition is simply done by the merchant, by changing MIDs (from test MID to production MID).


The URLs

Client redirection : URLSucess & URLFailure

Axepta redirects the buyer to a merchant page based on the payment result :

  • URLSuccess: "Successful payment" page of the merchant if the payment is successful
  • URLFailure: Merchant "Payment Failure" page if payment failed

When payment is made, the customer is redirected to the merchant’s store via HTTP GET.

Axepta then returns a HTTP status 302 (moved object) and attaches the payment status as a Blowfish encryption parameter to URLSuccess or URLFailure.


Notification to Merchant Information System: URLNotify

After execution of the payment, the payment solution notifies the shop of the payment result.

How ? :

The payment solution calls URLNotify via HTTP POST. This is a completely separate communication from the original connection between the store, the buyer and the payment solution.

Notify is only allowed via Port 443 (TLS) for security reasons.

If the store’s URLNotify is not accessible (e.g. HTTP status 500/404), the notification is repeated 8 times in 24 hours.


The data of reconciliation


Certain data allow the merchant to make the link between the initialization of a payment and the actual payment:

Reference number (RefNr) or archive reference:

The archival reference or "RefNr" is a field that must be conveyed in all your requests. It's present in all Axepta reports.

This is a mandatory parameter of 12 alpha-numeric characters (only digits & letters).


Transaction ID (TransID)

This field represents the reference of the single transaction in the form of a mandatory parameter of 64 alpha-numeric characters that may contain special characters.

This data is present in all Axepta reports.


Basket Description (orderDesc)

This field is used to set data (descriptions of items/products purchased) that will be returned to the merchant as is.

It can also be displayed on the payment page (customField) and is transmitted from the payment request to the reconciliation file.

This data is present in all Axepta reports.


Reconciliation Key Data Synthesis: Reconciliation: Key Data


Response codes

The return codes are in the form of an 8-character code divided into 3 blocks: N8, ( N NNNNNNN)

  • N (status)
  • NNN (Category)
  • NNNN (details)

Example of a return code:

2 206 0203

  • 2 Error
  • 206 3DS credit card adapater for authorization GICC protocol
  • 0203 Card brand does not support 3DS

Link to full list of return codes: Response codes

Link to 3DSv2 return code list: 3DS Response Codes

  • No labels