Changelogs
API v2.3
This version includes improvements to the Payments API.
Set X-Api-Version
header to 2.3
to use v2.3 of the API.
Payments API
Improvements
- The Payments API endpoints were modified to return error code
IdempotencyKeyAlreadyExists
with status409
when a payment request is submitted with anX-Idempotency-Key
that was already sent in a previous request. - The payment creation endpoint was improved to return the correct paymentMethodType
- The payment status webhook was improved to return the correct paymentMethodType
API v2.2
This version includes improvements to the Client Session API, Payments API and the Payment Methods API.
You must set the X-Api-Version
header to 2.2
to use v2.2 of the API.
Client Session API
- Added
order.lineItems.productData
on the request and response
Payments API
- Added
order.lineItems.productData
on the request and response
API v2.1
Version 2.1 includes improvements to the Client Session API, Payments API and the Payment Methods API.
Starting API v2.1, the API Version X-Api-Version is a semantic version without a patch (e.g. 2.1) rather than a date 🎉
Set the X-Api-Version
header to 2.1
to use v2.1 of the API.
Client Session API
- Added
paymentMethod.paymentType
andpaymentMethod.descriptor
on the request and response of the client session - Added
order.lineItems[].productType
on the request and response of the client session - Added
GET /client-session
to get the content of a client session - Added
PATCH /client-session
to update the content of a client session - Additional validation has been put in place to ensure that a
currencyCode
is always passed if anyamount
value is passed
Payments API
- Added
paymentMethod.isVaulted
boolean field to indicate whether thepaymentMethod.paymentMethodToken
in the response is a vaulted token (and can therefore be used for future payments) or not. This replacesvaultedPaymentMethodToken
. - Added
order.lineItems[].productType
on the request and response amount
,currencyCode
,customerId
andorderId
are now required fields when making a payment with a vaulted token (i.e. a recurring payment).- When paying with a vaulted token, additional validation has been put in place to ensure the
customerId
matches thecustomerId
associated with the vaulted token.
Payment Methods API
- Added verify in
POST /payment-instruments/{paymentMethodToken}/vault
to set whether or not the payment method token should be verified before vaulting - Added
isVerified
to the payment method response
API v2
Version 2 includes improvements to the Client Session API and the Payments API.
Client Session API
X-API-Version
->2021-09-27
- Creating a payment using only a payment method token is now possible. The
order
,customer
andmetadata
passed on the Client Session request is then used for the payment. - The create Client Session endpoint request was extended to include
order
,customer
, etc. - All references to
paymentInstrument
from the previous Payments API version have been refactored topaymentMethod
to be more consistent throughout - The customer
billingAddress
andshippingAddress
fields are now all optional
Payments API
X-API-Version
->2021-09-27
- Creating a payment using only a payment method token is now possible. The
order
,customer
andmetadata
passed on the Client Session request is then used for the payment. - The create payment endpoint request was extended to include
order
,customer
, etc. It now more closely resembles the/client-session
endpoint - The response of all the Payments API endpoints was refactored to match the create payment request structure
- All references to
paymentInstrument
from the previous Payments API version have been refactored topaymentMethod
to be more consistent throughout - All the payments API endpoints (create, capture, cancel, refund, etc.) are now versioned
paymentMethodData
inPaymentMethod
responses (for card payment method types) all now contain afirst6digits
field in addition to thelast4digits
returned. This is an opt-in field, so it isnull
by default.- The customer
billingAddress
andshippingAddress
fields are now all optional