Menu

Versioning and Change log

This log details any breaking and non-breaking API changes we have released for our Payments service.

Prerequisite: Make yourself familiar with ourAPI Principlesto ensure a resilient integration.

Versioning log

Note: Version 4 is the first major version used by merchants.

Breaking changes

Version 6 introduces reasons for entering into a repeat payment agreement.

  • header change to "Content-Type: application/vnd.worldpay.payments-v6+json"
  • new mandatory field intent for allrecurring resources
  • removed code and type fromerror messages

Breaking changes

Version 5 supports3DS2. API changes for this:

  • header change to "Content-Type: application/vnd.worldpay.payments-v5+json"
  • new mandatory field type
  • new mandatory field version
  • xid to transactionId

Breaking changes

  • Header change to "Content-Type: application/vnd.worldpay.payments-v0.4+json"
  • New mandatory field entityReference

Note: You can find documentation for all versionshere.

Change log (Non-breaking changes)

You can now receive a rawCode in all refusal responses. Seeraw response codesfor more information.

You now receive a paymentInstrument object in authorized responses to yourauthorization request, and Sent for Settlement responses to yoursale requestfor card/plain, card/token, and card/checkout.

You can now use our card/networkToken paymentInstrument with ourone time authorizationandmigrateCardOnFileAuthorizeendpoints.

You can now use our card/networkToken+applepay paymentInstrument with ourone time authorizationendpoint.

You can now submit a new intent value of subscription in yourcard on filerequest.

Theresponse of a partial refund requestreturns a link to allow you to perform another partial refund. The json path to the link in the response is $._links.payments:partialRefund.href.

We have added a new set of Mastercard refusalAdvicemagic values. This enables to you to test the different refusal outcomes in your Payment response.

You can now supply payment facilitator subMerchant email and telephone number in yourauthorization request.

The payment facilitator state field in theauthorization requestnow supports 1-3 alphanumeric characters.

You now have an option to specify a payment channel as moto to accept Mail Order Telephone Order (MOTO) payments with ourauthorize,migrateCardOnFileAuthorizeandmigrateCardOnFileSaleendpoints.

You can now submit your riskProfile to ourcard on file (with verification)endpoint in your payment requests. You then receive an exemption result and reason in the response.

Use it to apply theSCA exemptionin the payment request and update theFraudSightdata model to benefit future payments.

You can now use our card/networkToken paymentInstrument in our`payments:migrateCardOnFileSaleendpoint.

You can now submit the scheme reference in yourmigrateCardOnFile tokenandmigrateCardOnFileSale tokenrequests.

This request parameter allows you to take a repeat payment with our APIs, linking to an agreement established with a different PSP.

You now receive an exemption result and reason in yourcard on file saleandcard on file authorizationresponse if you have provided a riskProfile in your request.

You now receive an exemption result and reason in yourauthorization responseif you have provided a riskProfile in your request.

You now receive a verificationFailed result in yourauthorization responseif the issuer identifies a conflict.

The paymentInstrument.cardHolderName field is no longer mandatory in v6 payment requests.

You can now submit your riskProfile to ourmigrate card on file (without verification)andone timeendpoints in your payment requests. Use it to apply theSCA exemptionin the payment request and update theFraudSightdata model to benefit future payments.

You can now useApple Pay decryptedin our payments:migrateRecurringAuthorize endpoint to make a payment.

You can now useApple Pay decryptedin our payments:migrateCardOnFileAuthorize endpoint to make a payment.

You can optionally supply billingAddress details in the paymentInstrument forMobile Wallet payment requests.

We now return AVS results in riskFactors for ourMobile Wallet payment responses.

This request parameter allows you to take a repeat payment with our APIs, linking to an agreement established with a different PSP.

We have extended ourformattingrules.

  • you can now submit "+" in the transactionReference field

This change caters for the new mandate (July 2020) to allow merchants with MCC 7995, 7800, 7801, 7802 and 9406 to submit CVC in card on file requests.

  • the responsefor our wallet payment requests (Apple Pay/ Google Pay) now includes the paymentInstrument
  • We are returning riskFactors in our refused responses
  • You can now submit cvc for requests using tokens
  • From
    500 - serviceUnavailable
    to
    400 - expiredCard

The following characters are now allowed:

  • _/!@#$%()*=-.:;?[]-{}&~`
  • 0123456789
  • ABCDEFGHIJKLMNOPQRSTUVWXYZ
  • abcdefghijklmnopqrstuvwxyz