Payment notification

In case of Redirect Integration or Backend2Backend Integration which involves user redirection to a payment system web site (e.g. Paypal or eps) a post-processing step is required after that payment has been finished. This step involves checking the transaction state and updating the customer's order. The logic resides in the merchant's application.

To accomplish the above, mPAY24 provides the Confirmation Interface. There are two methods to receive transaction change information: pull and push. These two methods can also be combined. Push notifications are recommended as they can be applied in a more general way.

📘

The Confirmation Interface is the only legit option for the merchant's system to be informed about the transaction state (change).

🚧

Never attempt to use the redirection to the success or error page as confirmation of a transaction state. These URLs can be requested by the customer's web browser and therefore are highly unreliable and irreproducible.

Pull method

The merchant's system pulls the payment result from mPAY24 by invoking the TransactionStatus request on the success page. It can be used also at any other time for obtaining the current state of a payment. The TransactionStatus operation can be used with the mpaytid or tid, yet if possible the mpaytid should be used, since several transactions with the same tid could exist.

Note: The TransactionStatus request should be initiated only up to three times for a single transaction.

Further informations about the states can be found in chapter Transaction states.

Push method

The mPAY24 system notifies asynchronously the merchant's system via HTTP GET call about the payment state changes. The merchant has to implement a listener to these calls to process transaction changes in the merchant system.

Note: Multiple identical notifications can be sent for a single transaction. If a transaction notification is received again, it should be ignored by the merchant's system.

By implementing a single listener the merchant application can subscribe to a wide range of notification, which can be in relation to either payments triggered by the customer or the merchant's applications or by any payment modifications (e.g. via the mPAY24 merchant portal). That is why the push method is superior to the pull method and recommended by mPAY24.

Securing

An important security measure is to check the IP address of the confirmation call (see chapter Test and productive system).

Further mPAY24 strongly advises to check the values of the received confirmation with the information known of the transaction (e.g. a transaction record on the merchant's site like a saved order of a shop system).

To ensure security, the merchant should add a parameter to the ConfirmationUrl filled with a generated hash value of the tid, amount, currency, timestamp of the transaction and a random number. Additional this hash value should be saved in the merchant’s shop system for comparison and checking of received confirmations.

Implementation example

Notification values

The current default configuration of the Confirmation Interface returns the following values upon a transaction change. The mPAY24 Support should be contacted for further information about account configurations.

📘

Fields not provided in the initial request or information not entered upon the mPAY24 PayPage are returned empty.

Table: Notification values of the Confirmation Interface

Redirect

The merchant can define URLs (successURL, errorURL and cancelURL) which are used by mPAY24 to redirect the customer after a payment. These URLs can be either set in the merchant portal or within an operation (e.g. SelectPayment).

Since the URLs are requested by the customer's browser and should be considered as highly unreliable and insecure. The push or pull method has to be used to determine the state of a transaction.

The URLs are supplied to mPAY24 upon request. Any parameter may be appended. mPAY24 specific parameters are appended after the parameters defined by the merchant. New parameters may be added without notice.

The customer's browser requests the URLs via HTTP GET.

SuccessURL

Table: Values of the successURL

ErrorURL

Table: Values of the errorURL

CancelURL

No parameter provided by mPAY24.