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 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 ourcard on fileandone 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