API Principles

API principles

This section gives you an overview of the standards we are following to create a market-leading API.

Authentication and Identity

We use a single set of basic auth credentials for all our Access APIs. However, we use a different set between the Try (test) and Live environment.

For clientside SDKs, we create a public checkout Id that is mapped to your accounts API credentials. With this, we initialize the SDK.

OpenAPI Schema / Discovery

Every API has a schema available in OpenAPI format using version 3.0.1+, this is linted (checked) for syntax accuracy automatically. If you spot any inaccuracies, you can flag it, using the page comment tool (thumbs up/down) that is on every page.

Discovery for older services was originally handled by first querying the root resource. This is no longer necessary and we are slowly phasing it out as new breaking API versions are introduced. Our service URIs are stable and unlikely to change. A direct call simplifies the integration.

Versioning

We're migrating APIs to a new way of setting the version. Therefore you will see a different approach depending on the API's you're using.

Latest standard

New or updated APIs such as Payments or APMs use:

  • version header WP-Api-Version
  • a date e.g. 2024-06-01 indicating the initial release or latest breaking version. See breaking versions
  • The Content-Type for these APIs is also simply application/json

Previous standard

For APIs that have yet to be updated to the newer standards (e.g. Card Payments / 3DS) the Media Type is used to specify the version e.g.:

  • Content-Type: application/vnd.worldpay.fraudsight-v1.hal+json

Breaking & Non-breaking changes

For changes that alter the existing behavior, resource names, objects or key:values, a new API version is required, these are breaking changes. This could be a new feature that, with the existing API design, is not possible or a a new API standard that needs adopting across APIs.

There are various cases where an API will change but it is considered non-breaking. For example introducing new key:values is not considered breaking as your application code should only be checking for the values it was originally integrated against. Your integration must be resilient enough to handle these being introduced.

More examples of non-breaking changes:

In Responses:

Changing URIs/URIS and their FQDNs/paths

The structure and length of a URI/ URI including the Fully Qualified Domain Name (FQDN) and their path might change.

Example:

{
    "_links": {
        "service:action": {
            "href": "https://access.worldpay.com/service/action"
        },

or

{
    "_links": {
        "service:action": {
            "href": "https://api.access.worldpay.com/api/process"
        },
Reordering elements

Elements within the response body can be sent in any order.

Example:

{
    "apple": "gala",
    "pear": "conference"
}

or

{
    "pear": "conference",
    "apple": "gala"
}
New elements

A new object or new attributes within an object are now included in your response.

Example:

Before

{
    "apple": "gala",
    "pear": "conference"
}

After

{
    "apple": "gala",
    "pear": "conference",
    "melon": "honeydew"
}
New links and relationship types

Additional action links and URI resources are now returned within your response.

Example:

Before

{
    "_links": {
        "service:action1": {
            "href": "https://access.worldpay.com/service/action1"
        },
        "service:action2": {
            "href": "https://access.worldpay.com/service/action2"
        }
    }
}

After

{
    "_links": {
        "service:action1": {
            "href": "https://access.worldpay.com/service/action1"
        },
        "service:action2": {
            "href": "https://access.worldpay.com/service/action2"
        },
        "service:action3": {
            "href": "https://access.worldpay.com/service/action3"
        }
    }
}
New enumerate errors

Additional errors may be added when new features warrant a new error condition. Additional validation errors may be added if new optional elements are added to the request.

New HTTP error codes

Additional HTTP error codes may be added when new features warrant a new error condition.

New headers

A new HTTP header is now added to our response.

In Requests

Sending any elements not recorded in our documentation will return an error.

Reordering elements

Elements within the request body can be sent in any order.

Example:

{
    "apple": "gala",
    "pear": "conference"
}

or

{
    "pear": "conference",
    "apple": "gala"
}
New optional elements

New elements that are not mandatory can now be sent. For example merchant.mcc in our Payments API or description in our Tokens API.

Example:

Before

{
    "apple": "gala",
    "pear": "conference"
}

After

{
    "apple": "gala",
    "pear": "conference",
    "melon": "honeydew"
}
Increase in element value size

The value of an element now allows for an increased number of characters.

Example:

Before

{
    "phrase": "the quick brown fox"
}

After

{
    "phrase": "the quick brown fox jumps over the lazy dog"
}
Increase in format/scope of an element value

Changes in validation rules mean that requests which previously resulted in an error may now not.

Example:

A "time" value which previously allowed only hours and minutes, now also optionally allows seconds.

Before

{
    "time": "11:50"
}

After

{
    "time": "11:50:59"
}
Increase in range values

We may expand the range of values we accept. This means requests that previously resulted in a validation error may now succeed.

For example, previously allowed range value was 10-50. New range is 10-100.

New enumerate values

Element value options have now increased.

Example:

Previously allowed value options are apple, pear and melon. You could now also submit mango.

Before

{
    "fruit": "apple"
}

After

{
    "fruit": "mango"
}

Type of Integration

  • Modular - APIs with a single distinct purpose. E.g. 3DS authentication, create and manage tokens. You could use these:

    • to create custom/complex payments flow e.g. 3DS authentication with a long gap before the payment
    • as a gateway agnostic fraud assessment or 3DS authentication for use with multiple 3rd party payment gateways

  • Orchestrated - To simplify the integration we wrap various modular APIs to form common journeys. Our Payments API is the main example of this, allowing risk assessment, 3DS authentication, token creation and the card payment itself to be conducted in a single API.

Consistent Language

Focusing on making our APIs as easy to integrate and use, the language across different services is aiming to be same. This ensures learnabilty, usability and quick integration.

The billingAddress or email key:value on one API should be the same as another when used in the same context. Where it's not currently, these will be updated in a future new API version.

Whilst not strictly supporting HAL (Hypertext Application Language) we take some of the elements of it to make the actions, you could perform next, clear .

As with versioning you will see a different approach depending on the API's you're using.

Latest Standard

  • Uses a combination of _link mostly for self querying
  • _actions for the next possible steps you could take (e.g. cancel a payment)
{
"_links": {
    "self": {
        "href": "https://try.access.worldpay.com/api/payments/eyJrIjoiazNhYjYzMiIsImxpbmtWZXJzaW9uIjoiNS4wLjAifQ%3D%3D.sN%3Ag8wd64bwkbrp0md%2BbPxcanBnk2zLdsIqSa1pR99GeDrCwEtsymFb5gQw9WlrStDTK3eIWPy93y%3A7njc4649JSrU7%2BvFDl1J36%2BcwOkX0lW4Z%2BfnZKMutoUGX3m1%3AmZ%2BxHZ9nDpadu%2BBh7pRyJwnWeiSFTlqKvbrBxNm3HV0xann55pFjZ7qi4DNGZtx9zW6eOLVNOsPL6ecsn3Dp377s7pWRQKSZJKSFIJvAisP8cBzFPzqireuqfCu5ojcm60gRSsqS3glurO24RJkg5SrpRjgY6g7ca8uoA7tKDk9OVOIwORF5sGPHSSGMa2bEl2lMUkAANoWclQHiGzxWQQ%3AAwSoo6RsrBugbhEp0K8HxZkfVrqy4oVlW8FdQ7kIuZOH78i6pPLzArc%2BOtMdnU%3ArZ%3AVhRHFzbbwymcuTiRbNw%3D"
    }
},
"_actions": {
    "cancelPayment": {
        "href": "https://try.access.worldpay.com/api/payments/eyJrIjoiazNhYjYzMiIsImxpbmtWZXJzaW9uIjoiNS4wLjAifQ%3D%3D.sN%3Ag8wd64bwkbrp0md%2BbPxcanBnk2zLdsIqSa1pR99GeDrCwEtsymFb5gQw9WlrStDTK3eIWPy93y%3A7njc4649JSrU7%2BvFDl1J36%2BcwOkX0lW4Z%2BfnZKMutoUGX3m1%3AmZ%2BxHZ9nDpadu%2BBh7pRyJwnWeiSFTlqKvbrBxNm3HV0xann55pFjZ7qi4DNGZtx9zW6eOLVNOsPL6ecsn3Dp377s7pWRQKSZJKSFIJvAisP8cBzFPzqireuqfCu5ojcm60gRSsqS3glurO24RJkg5SrpRjgY6g7ca8uoA7tKDk9OVOIwORF5sGPHSSGMa2bEl2lMUkAANoWclQHiGzxWQQ%3AAwSoo6RsrBugbhEp0K8HxZkfVrqy4oVlW8FdQ7kIuZOH78i6pPLzArc%2BOtMdnU%3ArZ%3AVhRHFzbbwymcuTiRbNw%3D/cancellations",
        "method": "POST"
    }
}

Previous Standard

  • Contains only the _links object
  • Also contains _curies for accessing the schema of a given resource. Phased out in favour of OpenAPI schema.
{
    "_links": {
        "cardPayments:cancel": {
            "href": "https://try.access.worldpay.com/payments/authorizations/cancellations/eyJrIjoiazNhYjYzMiI="
        },
        "cardPayments:settle": {
            "href": "https://try.access.worldpay.com/payments/settlements/full/eyJrIjoiazNhYjYzMiI="
        },
        "cardPayments:partialSettle": {
            "href": "https://try.access.worldpay.com/payments/settlements/partials/eyJrIjoiazNhYjYzMiI="
        },
        "cardPayments:events": {
            "href": "https://try.access.worldpay.com/payments/events/eyJrIjoiazNhYjYzMiI="
        },
        "curies": [
            {
                "name": "cardPayments",
                "href": "https://try.access.worldpay.com/rels/cardPayments/{rel}",
                "templated": true
    }
  }
}

The links themselves can be either static to simply inform you of the next possible action or dynamic so as to embed/contain details to be used in the next action and are therefore unique to an individual transaction.

Note

The maximum length of the encrypted action link data excluding the base URL will be up to 1024 characters.

Logging for Support Purposes

Access Worldpay returns a WP-CorrelationId in the headers of service responses. We highly recommend you log this. The WP-CorrelationId is used by us to examine individual service requests.

You should now familiarize yourself with our security best practices.