Changelog

Every public-facing change to the Developer API. Newest first. Click Before / Now on any entry to see the full detail and migration guidance.

Unreleased

No changes queued. Items in flight will land here before the next release is cut.

6.7.0 (fullstack sprint 2026)

Status: Released. Date: TBD. Source: fullstack sprint 2026.

The sprint focuses on Card-on-File (COF) groundwork, debit-flow parity with sale, richer callback / status payloads, and three breaking changes for partners to plan around.

Breaking

Status-lookup error code change

Breaking · Checkout · S2S CARD · S2S APM

Status-lookup requests with an invalid identifier now return a specific error message and a distinct error code.

Before / Now

Before. Any invalid identifier on GET_TRANS_STATUS returned a generic:

{ "http_code": 400, "error_code": "100000", "error_message": "This value is not correct." }

Now. HTTP 400 stays. The not-found code and message depend on the entity the operation targets, not on whether the operation is a read or a mutation. The migrated entities are transaction and order; payment, schedule, and recurring entities continue to return 100000 with their own specific messages.

Operation	Entity	Code	Message
Checkout `GET_TRANS_STATUS` by `payment_id`	payment	`101000`	`Payment does not exist.`
Checkout `GET_TRANS_STATUS` by `order_id`	order	`101000`	`Order does not exist.`
S2S CARD `GET_TRANS_STATUS` by `trans_id`	transaction	`101000`	`Transaction does not exist.`
S2S CARD `GET_TRANS_STATUS_BY_ORDER` by `order_id`	order	`101000`	`Order does not exist.`
S2S CARD `CAPTURE` against unknown `trans_id`	transaction	`101000`	`Transaction does not exist.`
S2S CARD `VOID` against unknown `trans_id`	payment	`100000`	`Payment not found.`
S2S CARD `CREDITVOID` against unknown `trans_id`	payment	`100000`	`Payment not found.`
S2S CARD `DELETE_SCHEDULE` against unknown `schedule_id`	schedule	`100000`	`Schedule not found`
S2S CARD `UPDATE_SCHEDULE` against unknown `schedule_id`	schedule	`100000`	`Schedule not found`
S2S CARD `RECURRING_SALE` against unknown init pair	recurring	`100000`	`Incorrect transaction`
S2S APM equivalents	(not yet audited; per-entity pattern is assumed to hold — confirm before depending on it)

Migration. Do not simply change error_code == "100000" to error_code == "101000" everywhere. The new 101000 is returned only for operations whose underlying entity is a transaction or order. Operations against the payment, schedule, or recurring entities still return 100000 with their own specific messages, so a blind code swap will miss those cases. Key off the per-operation row in the table above, or match on error_message in addition to error_code. See the API error reference for every row that maps a code + message pair to a producing action.

S2S CARD payer fields demoted to optional

Breaking · S2S CARD

payer_address, payer_country, payer_city, payer_zip are no longer mandatory on S2S CARD requests; the requirement is now configurable per Protocol Mapping.

Before / Now

Before. The four payer fields were required at the API layer for all S2S CARD requests.

Now. Each field is enforced only when its Protocol Mapping setting is configured to Required. WL / TuskPay mappings ship with the fields marked Optional.

Migration. No action needed for callers that already send all four fields. If your back office relies on the API rejecting requests with missing payer details, move the validation into your own pre-submit check; do not rely on Akurateco's request validator to enforce these four fields any more. The connector-side acquirer may still reject the request if it requires the data.

Payment Mode routing logic with new SMS/DMS default

Breaking · Checkout · S2S CARD

MID Payment Mode gains a third value SMS/DMS (now the default), and routing logic for the new auth parameter changes how MIDs are selected.

Before / Now

Before. MID Payment Mode was SMS or DMS. Checkout could not issue an authentication-only purchase.

Now. Three values:

SMS (single-message: auth + capture together)
DMS (dual-message: auth, then capture later)
SMS/DMS (new default; the MID can serve either flow)

A new optional auth boolean parameter on purchase:

`auth`	MIDs eligible	Operation issued
`false` (default)	`SMS` + `SMS/DMS`	Sale
`true`	`DMS` + `SMS/DMS`	Auth (capture later)

Migration. Existing merchants without an explicit Payment Mode configured are migrated to SMS/DMS. If your routing depended on two-mode behaviour (e.g. routing rules that match exactly SMS or exactly DMS), update them to handle the third value. Senders that omit auth retain previous Sale behaviour. To request an auth-only purchase on Checkout, send "auth": true on the purchase operation.

Added

card_token in CREDIT operations

Added · Checkout

Tokens from previous PURCHASE or DEBIT operations can now drive CREDIT requests; the payer is prompted only for expiry, never for CVV.

Before / Now

Before. card_token on credit had no effect: the payer still had to enter full card data on the Checkout page.

Now. Credit accepts card_token. The payer is prompted for MM / YY only; CVV is not collected. Payee name is prefilled from the original token, or overridden by payee_first_name + payee_last_name if those are sent (request parameters take priority).

POST /api/v1/payment/card/credit
{
  "merchant_key": "27106696-...",
  "operation": "credit",
  "order": { "number": "test-10984", "amount": "10.00", "currency": "USD", "description": "..." },
  "card_token": ["159e793cf746735e71dbd857dd71b5765adb2f76b87e1911c6655e59c0bd4b1c"],
  "name": "John Doe",
  "hash": "{{operation_hash}}"
}

Part of the credit with skip redirection and card_token change.

custom_data in Recurring (Secondary Sale)

Added · Checkout

Recurring (Secondary Sale) requests now accept custom_data, and the callback returns the new value rather than the initial-payment value.

Before / Now

Before. custom_data could be sent only on the initial Authentication request. Recurring requests rejected it, and callbacks always echoed the initial-payment value.

Now.

custom_data is accepted in Secondary Sale (recurring) requests.
The callback returns the recurring-request custom_data, not the initial-payment value.

Structure is a free-form object stored with the transaction; not connector-related.

Size parameter in GET_TRANS_STATUS by order_id

Added · Checkout

A new optional size parameter (1..100) returns up to N most recent payment_ids sharing one merchant order_id.

Before / Now

Before. The endpoint returned only the newest payment_id for a reused order_id, hiding older attempts.

Now. Send size to retrieve up to 100 most recent attempts:

{
  "merchant_key": "27106696-...",
  "order_id": "test-012345",
  "size": "100",
  "hash": "{{operation_hash}}"
}

Response shape:

size omitted: object (original shape, single payment).
size = 1: array with one object.
size in 2..100: array with N objects.
size > 100: error size should be within 1..100.

Recurring Debit and debit schedules

Added · Checkout · S2S CARD

Debit operations gain full recurring support: recurring_init=true on the first debit, a Secondary Sale request for subsequent charges, and schedule support that mirrors sale schedules.

Before / Now

Three workflows shipped together.

Init recurring debit. Send recurring_init=true on a Checkout debit (operation=debit). The success callback returns recurring_init_trans_id, recurring_token, and schedule_id (when used).
Secondary recurring sale. Send the Checkout RECURRING request with recurring_init_trans_id + recurring_token to charge again without re-collecting card data.
Schedules for debits. schedule_id works identically to sale schedules. Schedules are not type-separated; CREATE_SCHEDULE / PAUSE / RUN / DELETE / INFO / DESCHEDULE all support debit-initiated chains.

The S2S CARD equivalent is the new RECURRING_DEBIT command.

custom_data in Checkout debit and credit

Added · Checkout · S2S CARD · S2S APM

custom_data is now accepted on Checkout debit and credit requests, and on the S2S Card / S2S APM equivalents.

Before / Now

Before. custom_data was rejected on debit and credit operations.

Now. Free-form object is accepted on debit and credit, stored with the transaction, and returned in the callback notification. No connector-side mapping; it is opaque end-to-end.

Card-on-File (COF) flow in Checkout and S2S CARD

Added · Checkout · S2S CARD

When the MID has card_on_file_support enabled, the platform requests COF generation from the connector. The resulting recurring_token is stored and made available for subsequent payments via the RECURRING flow.

Before / Now

New workflow.

The platform requests COF generation from the connector when the MID has card_on_file_support enabled.
The COF (recurring_token) is stored with the transaction and made available for subsequent payments.
Subsequent payments use the RECURRING flow.
A new payer_present parameter on SALE and DEBIT (S2S CARD).
New attributes on transaction details, callback, and GET_TRANS_STATUS responses: initiator, sequence, source (configurable).

auth parameter in Checkout

Added · Checkout

Checkout can now request an authentication-only purchase. (See the Breaking entry above for the routing-logic change that ships with this.

Before / Now

Before. The auth parameter was available only in S2S; Checkout could not request authentication-only payments on the same MID.

Now. New parameter:

Parameter	Type	Required	Description
`auth`	boolean	optional, default `false`	Indicates the transaction must be only authenticated, not captured. Only valid for `purchase`.

Routing logic:

`auth`	MIDs taken	Operation
`false`	SMS + SMS/DMS	Sale
`true`	DMS + SMS/DMS	Auth + capture

Override Link Target on MID for url_target

Added · Checkout · S2S CARD

A new MID attribute Override Link Target lets administrators force a specific url_target (Checkout) or term_url_target (S2S CARD) regardless of the merchant-supplied value.

Before / Now

Before. Whatever value the merchant sent in url_target was used verbatim; there was no admin-side override.

Now. A new MID attribute Override Link Target accepts _blank, _self, _parent, or _top.

Logic:

If the merchant sends url_target and Override Link Target is unset, the merchant value is used.
If Override Link Target is set on the MID, the MID value is used unconditionally.

iframe handling. When the flow proceeds with _top inside an iframe, the customer sees a "Click Continue to proceed with the payment" message and a Continue button. Clicking opens a new window to continue the payment. This wrapper applies to any target that needs to break out of the iframe.

Checkout Payment Method in callback, status, and return URLs

Added · Checkout

A new Checkout Payment Method Protocol Mapping option returns the CHECKOUT-terminology payment method name (e.g. applepay, card) in callbacks, GET_TRANS_STATUS, and the success_url / cancel_url query string.

Before / Now

Key. checkout_payment_method. Value. Payment method name in the CHECKOUT terminology (e.g. for Apple Pay even with token decryption it is applepay; for VISA cards it is card).

Redirect example:

https://your-success-url?payment_method=card
https://your-success-url?payment_method=applepay

Return additional parameters block in Protocol Mapping

Added · Checkout

A new Return additional parameters drag-and-drop block in Protocol Mapping appends extra parameters to success_url and cancel_url. The initial available parameter is Payment method.

Before / Now

Behaviour.

Block appears under the existing Return parameters checkbox.
Selected parameters are appended as query parameters on success_url and cancel_url.
The selected list is empty by default.
Initial available parameter: Payment method.
The same parameter is also added to the Add Data to drag-and-drop block, so it returns in callback and GET_TRANS_STATUS responses.

A tooltip next to the Return parameters checkbox spells out the always-returned parameters: payment_id, trans_id, order_id, hash.

Return parameters now appended for 3DS payments

Added · Checkout

Return parameters are appended to success_url and cancel_url for both 3DS and non-3DS payments.

Before / Now

Before. Return parameters were appended only on non-3DS payment redirects. 3DS redirects lost them.

Now. Parameters are appended in both cases. Example payload:

{
  "result": "completed",
  "return_url_query_params": {
    "payment_id": "1f796804-d759-...",
    "trans_id":   "22b231ae-d759-...",
    "order_id":   "00000000-0000-0000-0000-000000000006",
    "hash":       "2326871dd2c860d364d594ab32c948e292fab3d3",
    "payment_method": "card",
    "brand":      "visa"
  }
}

ard and card_expiration_date in GET_TRANS_STATUS

Added · Checkout · S2S CARD

The masked card number and expiration date are now returned in GET_TRANS_STATUS responses; previously they appeared only in the callback.

Before / Now

Two parameters added to Protocol Mapping → Add Data to Get status response:

card: masked card number (e.g. 411111****1111)
card_expiration_date: MM/YYYY

Returned in both GET_TRANS_STATUS by payment_id and GET_TRANS_STATUS by order_id.

brand in callback and redirect parameters

Added · Checkout · S2S CARD · S2S APM

brand is now available in the Protocol Mapping Add Data to Callback and Redirect parameters blocks.

Before / Now

Value is the brand name (e.g. payment_document_card, payment_document_virtual, payment_document_crypto).

ARN in callback and GET_TRANS_STATUS

Added · Checkout · S2S CARD · S2S APM

The acquirer reference number (ARN) is now configurable as a callback and status-response parameter, alongside RRN.

Before / Now

Available for. SALE, AUTH, RECURRING_SALE, REFUND, and the equivalent Checkout GET_TRANS_STATUS by payment_id and by order_id.

Behaviour.

Callback. If the value is missing, the parameter is sent with an empty value.
Status response. If the value is missing, the parameter is omitted.

COF initiator, source, sequence in callback and GET_TRANS_STATUS

Added · Checkout · S2S CARD · S2S APM

initiator, source, and sequence the COF discriminators introduced are now configurable in Protocol Mapping for callbacks and GET_TRANS_STATUS responses; they are also available as filters in transaction search.

Before / Now

Default. These fields are not sent in the callback. The merchant must enable each one in Protocol Mapping.

Field values. Defined (initiator type, transaction source, COF sequence position).

3DS attributes and browser data in callback

Added · Checkout · S2S CARD

Protocol Mapping → Add Data to Callback is extended with 3DS authentication result attributes and payer browser metadata.

Before / Now

3DS attributes.

Field	Description
`threeDSServerTransID`	3DS Server transaction ID.
`dsTransID`	Directory server transaction ID.
`acsTransID`	ACS (issuing bank) transaction ID.
`xid`	Main 3DS v1.0 transaction ID.
`transStatus`	Authentication status (`Y` success, `N` failure, `C` challenge, etc.).
`transStatusReason`	Additional reason code.
`eci`	Electronic Commerce Indicator.
`protocolVersion`	3DS protocol version.
`authenticationFlow`	Frictionless or Challenge.

Browser attributes (browser_*).

browser_color_depth, browser_screen_height, browser_screen_width, browser_java_enabled, browser_javascript_enabled, browser_language, browser_timezone_offset, browser_user_agent, browser_accept_headers, browser_platform.

Population logic.

If the payment went through External MPI: values are stored as-is.
If the payment went through the connector service or Checkout: values are populated by the collector.

Bonus. Transaction search filters added for threeDSServerTransID, transStatus, dsTransID, acsTransID, xid, and transFlow.

15 payer fields configurable in callback and status response

Added · S2S CARD · S2S APM

15 payer attributes are now individually configurable in Protocol Mapping for callbacks and GET_TRANS_STATUS responses.

Before / Now

payer_first_name, payer_last_name, payer_birth_date, payer_address, payer_address2, payer_house_number, payer_phone_country_code, payer_country, payer_state, payer_city, payer_district, payer_zip, payer_email, payer_phone, payer_ip.

Each field is enabled per mapping; default is off.

Changed

billing_address.state collected only for CA/US/JP/AU/IN

Changed · Checkout · S2S CARD (as payer_state)

The state field is now shown to the payer only when billing_address.country is CA, US, JP, AU, or IN. For other countries the field is hidden and not validated.

Before / Now

Before. The optional billing_address.state (or payer_state on S2S CARD) was collected from the payer for all countries, even where state is irrelevant.

Now. Field is collected only when country is one of:

CA (Canada)
US (United States)
JP (Japan)
AU (Australia)
IN (India)

For all other countries the field is omitted and no validation is applied.

Fixed

browser_info.accept_headers forwarded to MPGS

Fixed · Checkout · Hosted Payment Fields

browser_info.accept_headers is now read from the processing request and forwarded to the MPGS connector. Previously the connector received an empty value and rejected the request.

Before / Now

Before. The MPGS connector requires acceptHeaders in the AUTHENTICATE_PAYER request, but this field could not be passed through /api/v1/processing/purchase/card. The connector returned:

{
  "error": {
    "cause": "INVALID_REQUEST",
    "explanation": "Value '' is invalid. Length is 0 characters, but must be at least 1",
    "field": "device.browserDetails.acceptHeaders",
    "validationType": "INVALID"
  },
  "result": "ERROR"
}

Now. browser_info.accept_headers is mapped to payer_extra_details.accept_headers and forwarded to the connector's device.browserDetails.acceptHeaders field.

card_token in settled debit callbacks (hotfix)

Fixed · Checkout

Debit callbacks with order_status=settled now include card_token. Previously the token was present only on the order_status=3ds callback.

Before / Now

Hotfix on top of last fix.

Before. For debit transactions, card_token appeared in the callback with order_status=3ds but was missing from the subsequent callback with order_status=settled.

Now. card_token is included in every callback for debit operations, including settled.

card_token in every debit callback

Fixed · Checkout

card_token is now returned in every callback for the debit operation, matching sale-callback behaviour.

Before / Now

Before. card_token was returned only in the first callback of a debit operation; subsequent callbacks omitted it.

Now. Returned in every callback. Behaviour is consistent with sale callbacks regardless of operation type.

card data in debit callback when using card_token

Fixed · Checkout

Debit callbacks that use card_token now include masked card and expiration. This matches the long-standing behaviour for sale operations.

Before / Now

Before. Debit callbacks initiated via card_token did not include card data.

Now. Callbacks include:

card=512345****0008
card_expiration_date=01/2039

6.6.5 (2026-02-03)

Last released before the fullstack-sprint-2026 work. Carry-forward from the prior changelog stub; full per-entry write-up was not produced for this version.

Stabilisation release. Specific items to be backfilled if requested.

6.6.4 (2025-11)

Added. Memory Storage redirect mode.

6.6.3 (2025-09)

Added. DMS capture via API at /api/v1/payment/capture. See DMS mode.

6.6.2 (2025-07)

Added. extended_data field in callback payloads.

How to read this page

Each entry leads with a category badge (Added, Changed, Deprecated, Removed, Fixed, Security, plus Breaking when applicable) and the affected products.
Click Before / Now to expand the full change description with request and response examples.
For error-code-level detail (causes and fixes), see the API error reference.

Unreleased​

6.7.0 (fullstack sprint 2026)​

Breaking​

Status-lookup error code change​

S2S CARD payer fields demoted to optional​

Payment Mode routing logic with new SMS/DMS default​

Added​

card_token in CREDIT operations​

custom_data in Recurring (Secondary Sale)​

Size parameter in GET_TRANS_STATUS by order_id​

Recurring Debit and debit schedules​

custom_data in Checkout debit and credit​

Card-on-File (COF) flow in Checkout and S2S CARD​

auth parameter in Checkout​

Override Link Target on MID for url_target​

Checkout Payment Method in callback, status, and return URLs​

Return additional parameters block in Protocol Mapping​

Return parameters now appended for 3DS payments​

ard and card_expiration_date in GET_TRANS_STATUS​

brand in callback and redirect parameters​

ARN in callback and GET_TRANS_STATUS​

COF initiator, source, sequence in callback and GET_TRANS_STATUS​

3DS attributes and browser data in callback​

15 payer fields configurable in callback and status response​

Changed​

billing_address.state collected only for CA/US/JP/AU/IN​

Fixed​

browser_info.accept_headers forwarded to MPGS​

card_token in settled debit callbacks (hotfix)​

card_token in every debit callback​

card data in debit callback when using card_token​

6.6.5 (2026-02-03)​

6.6.4 (2025-11)​

6.6.3 (2025-09)​

6.6.2 (2025-07)​

How to read this page​

Unreleased

6.7.0 (fullstack sprint 2026)

Breaking

Status-lookup error code change

S2S CARD payer fields demoted to optional

Payment Mode routing logic with new SMS/DMS default

Added

card_token in CREDIT operations

custom_data in Recurring (Secondary Sale)

Size parameter in GET_TRANS_STATUS by order_id

Recurring Debit and debit schedules

custom_data in Checkout debit and credit

Card-on-File (COF) flow in Checkout and S2S CARD

auth parameter in Checkout

Override Link Target on MID for url_target

Checkout Payment Method in callback, status, and return URLs

Return additional parameters block in Protocol Mapping

Return parameters now appended for 3DS payments

ard and card_expiration_date in GET_TRANS_STATUS

brand in callback and redirect parameters

ARN in callback and GET_TRANS_STATUS

COF initiator, source, sequence in callback and GET_TRANS_STATUS

3DS attributes and browser data in callback

15 payer fields configurable in callback and status response

Changed

billing_address.state collected only for CA/US/JP/AU/IN

Fixed

browser_info.accept_headers forwarded to MPGS

card_token in settled debit callbacks (hotfix)

card_token in every debit callback

card data in debit callback when using card_token

6.6.5 (2026-02-03)

6.6.4 (2025-11)

6.6.3 (2025-09)

6.6.2 (2025-07)

How to read this page