Click here to search the entire website

Order notifications

A reliable and accurate way of automatically receiving changes to transaction statuses.

On this page:

Setting up notifications

Best practice:  For the Hosted integration we recommend that you turn on AUTHORISED notifications so that you can see the 3D Secure Authentication (3DS) results in <ThreeDSecureResult>. The example authorised notification below shows you the position of this element. The liability shift page explains the effect of these results.

The Merchant Channels functionality in the MAI allows you to configure which statuses you would like to receive order notifications for, through what channel and in what format.

Statuses reported

Worldpay can send a notification when a payment reaches one of these statuses:

Payment status Description

We've requested permission (from the card issuer) to process the shopper's payment.


The payment has been approved and the funds reserved in the shopper's account.

CAPTURED The funds reserved against the shopper's account have now been removed, and are travelling to your Worldpay/merchant account.

Applies to M/S - level service.

Funds have been received by Worldpay and are being prepared for transfer to your bank account.


Applies to C - level (gateway only) service.

The gateway has successfully instructed the acquirer to transfer the funds. Your acquirer will confirm the actual settlement.


The funds have been returned to the shopper, following the card issuer's decision.


Additional defence information has reversed a chargeback decision.


A card issuer has requested information about a transaction. The amount of the disputed transaction has been held until the outcome of the dispute.


You've sent us defence information for the dispute.


The payment request has been declined by a third party, or by the Risk Management Module (RMM).


The payment wasn't completed. Your shopper may want to reattempt it.


Either you or the Risk Management Module (RMM) have stopped the transaction.


The authorisation period ended before a capture or cancel request was made.


You've requested funds to be sent back to the shopper.


The refund couldn't be processed and the funds were returned to your account.


Applies to M/S - level service.

A confirmation that the issuer will process the refund and the shopper will receive it.


Applies to C - level (gateway only) service.

The gateway has successfully instructed the acquirer to process the refund. Your acquirer will confirm the actual refund.

Note:  Some payment statuses are not reported through order notifications. To check any possible status for a payment you can consult its payment details in the Merchant Administration Interface (MAI), or send an inquiry request. To learn about the flow of the different payment statuses, see The Payment Process.

When they're reported

Order notifications for the statuses AUTHORISED, CANCELLED (by Risk Management Module) and REFUSED are sent immediately when a payment has obtained one of these statuses. Order notifications for the other payment statuses are handled by a different mechanism and are typically sent within 15 minutes of being generated. 

Reporting channels

There are two channels (Email and HTTPS). With HTTPS, we only offer the XML format.

HTTPS notifications

HTTPS order notifications are sent to a URL on your system that can process the information contained in the message. The URL usually points to a page with script (ASP, PHP, Perl, CGI) that interprets the content of the notification, and sends the interpreted result through to your back-office system.

How to confirm the message is from Worldpay

Order notifications sent to your system may have direct impact on your delivery process, so we advise you to ensure the messages are genuine, such as:

  • Receiving the messages on a secure server

  • Checking the Worldpay client certificate for authenticity

  • Checking the sender's domain name

Secure server (HTTPS)

Using a secure server on your side will enable you to use the Secured HTTP (HTTPS) protocol to receive Worldpay order notifications. Even though the connection is secured, using the HTTPS protocol does not guarantee that it was actually Worldpay who sent the message.

Authenticating the sender

You can validate that the HTTP notifications are originating from Worldpay using one of these methods:

  1. Client certificates - configure your server to ask for a Worldpay TLS (SSL) certificate. We can send our certificate with all communications.

  2. Reverse DNS lookup - the domain is * Whilst this can place additional burden on a proxy server or firewall, we recommend this approach rather than using IP addresses. If you use IPs to validate notifications from Worldpay, this could fail when:

    • We change our RIPE IP addresses

    • We amend the Worldwide Payment Gateway RIPE address range

    • We invoke disaster recovery

    We will endeavour to advise you of changes to our IP range(s), but we can't guarantee that this will always happen.

How to acknowledge receipt

We're changing the way you acknowledge notifications, you will be able to test these changes from 5 September 2018 and they will be live from 10 October 2018.



The retry mechanism

If the notification is not successfully acknowledged, we initially wait 10 seconds before attempting to deliver the notification again. We'll then place it in a queue and attempt to resend it at increasing intervals of up to 2 hours for a period of 7 days. If acknowledged, or after a week, the retry mechanism stops sending the message and proceeds with the next notification from the queue.

The retry mechanism guarantees the delivery of order notifications for a week; however, it does not provide certainty on the time of delivery.

Order notifications for AUTHORISED, CANCELLED and REFUSED events (for online payment methods) are sent out by the payment server that processed the transaction. Therefore it is possible for you to still receive the above notification types when you have incorrectly acknowledged a previous order notification. The queue can be formed of:

  • Other incorrectly acknowledged order notifications

  • The AUTHORISED, CANCELLED and REFUSED events for offline payment methods

  • All other event types i.e. CAPTURED, since the mechanism responsible for re-sending incorrectly acknowledged notifications also sends these notifications

How to prevent queuing

To prevent a backlog of notifications, follow these three steps:

  1. Store

  2. Acknowledge

  3. Process

If you store and process the notification before acknowledging receipt, this may cause delays.

XML notifications

To interpret XML order notifications it is helpful to understand the payment process.

Note:  For XML notifications, the content-Type is text/xml; charset=UTF-8.

The notify element

Within the <paymentService> element, the message indicates that it's a notification (<notify>) on a status change of a specific order (<orderStatusEvent>), which in turn contains the orderCode:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE paymentService PUBLIC "-//Worldpay//DTD Worldpay PaymentService v1//EN"


<paymentService version="1.4" merchantCode="Your_merchant_code">


    <orderStatusEvent orderCode="ExampleOrder1"> <!--The orderCode you supplied in the order-->





Notify element

Payment details

The <payment> element contains the payment details for the order. Included are the:

  • <paymentMethod>

  • Original payment <amount>

  • Last payment status change (<lastEvent>)

  • Current <balance> for the order at the appropriate accountType in our system

This is an example of the payment information for a Mastercard (ECMC-SSL) payment for the amount of EUR 24 that has been AUTHORISED:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE paymentService PUBLIC "-//Worldpay//DTD Worldpay PaymentService v1//EN"


<paymentService version="1.4" merchantCode="Your_merchant_code">


    <orderStatusEvent orderCode="ExampleOrder1"> <!--The orderCode you supplied in the order-->



          <amount value="2400" currencyCode="EUR" exponent="2" debitCreditIndicator="credit"/>


<AuthorisationId id="622206"/>

        <balance accountType="IN_PROCESS_AUTHORISED">

          <amount value="2400" currencyCode="EUR" exponent="2" debitCreditIndicator="credit"/>



        <riskScore value="0"/>





Example notification on a Mastercard payment

Note:  It is possible that for certain off-line payment methods a status change has occurred after the event that is reported on, but before the notification is sent. This can also happen when a notification is sent via the retry mechanism. The payment element contains balance information at the time the order notification is sent. Hence, the accounts involved in the last status change are shown here.

Journal details

Once payments reach the AUTHORISED status, they are mapped to journals as they move through our system. These interactions are explained in the payment process.

The <journal> element contains useful information about the payment status and the movement of funds, so it is useful for tracking partial captures and refunds (you can also use the reference attribute in a capture or refund modification for this purpose).

It specifies:

  • The payment status (journalType)

  • The date the status was given (<bookingDate>)

  • The details of corresponding transactions (<accountTx>) between our accounts

Worldpay processes payments in batches, and the batchId indicates the batch in which the transfer has been processed. The debitCreditIndicator indicates whether the transfer is positive ("credit") or negative ("debit").

Example authorised notification

This is an example of an authorisation notification, where the status of the payment changes to AUTHORISED and an amount of EUR 24 is transferred to the account IN_PROCESS_AUTHORISED:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE paymentService PUBLIC "-//Worldpay//DTD Worldpay PaymentService v1//EN"


<paymentService version="1.4" merchantCode="Your_merchant_code">


    <orderStatusEvent orderCode="Your_order_code">



        <paymentMethodDetail> <!--Not returned by default - contact us to enable-->

          <card number="444433******1111" type="creditcard">

            <expiryDate> <!--Not returned by default - contact us to enable-->

              <date month="01" year="2020"/>




        <amount value="2400" currencyCode="EUR" exponent="2" debitCreditIndicator="credit"/>


<AuthorisationId id="622206"/>

        <CVCResultCode description="C"/>

        <AVSResultCode description="E"/>

        <AAVAddressResultCode description="B"/>

        <AAVPostcodeResultCode description="B"/>

        <AAVCardholderNameResultCode description="B"/>

        <AAVTelephoneResultCode description="B"/>

        <AAVEmailResultCode description="B"/>

        <ThreeDSecureResult description="Cardholder authenticated">

          <eci>05</eci> <!--Not returned by default - contact us to enable-->

          <cavv>MAAAAAAAAAAAAAAAAAAAAAAAAAA=</cavv> <!--Not returned by default - contact us to enable-->





        <riskScore value="0"/>


      <journal journalType="AUTHORISED" sent="n">


          <date dayOfMonth="01" month="01" year="2020"/>


        <accountTx accountType="IN_PROCESS_AUTHORISED" batchId="30">

          <amount debitCreditIndicator="credit" exponent="2" currencyCode="EUR" value="2400"/>






Example authorisation notification

Note:  For other events, more than one (or even none) <accountTx> may show up within the journal element. An example of an event with no associated <accountTx> transaction is REFUSED.

Other notification examples

Other journal examples

Modification requests