Skip to content

Changelog

Track every change to the Qore Payments documentation

All notable changes to these docs are listed by date and grouped into Added, Changed, Fixed and Removed.

All notable changes to the Payment Gateway documentation will be documented on this page.

2026-10-30

Added

  • Transaction Management API spec: the 422 response of /api/transactions/manage and the ErrorDto schema. A CREDIT can have a CAPTURE as its parent as well as a PURCHASE.
  • Transaction Status API spec: payment_provider_token.

Changed

  • Ilixium: a refund or credit whose answer was lost is settled from Ilixium's history, read every 5 minutes. If it is still PENDING 24 hours later, contact support.
  • Every integration: you see only the latest attempt of an order. The ID of an earlier attempt answers with the latest one in the Transaction Status API, GET /api/transactions/{id} and GET /api/sessions/{id}, and a capture, refund or void sent with it acts on the latest one (Transaction Management). Webhooks carry one outcome per order: a decline that can still be retried waits up to 15 minutes, and a retry's parent_id is null (match it by order_id). A refund's, capture's, void's, chargeback's or fee's parent_id is still the payment it acts on.
  • Hosted Payment Page and Embedded Fields: the status of the session_id is the latest attempt's.

2026-10-29

Added

  • New Provider Token payment method: pay again with a reusable card token your payment provider issued (today Ilixium), and read the token of an approved card payment as payment_provider_token in your server-to-server API response.
  • New Ilixium page: what card, Apple Pay, token, refund and credit payments routed to Ilixium need, and how their outcomes reach you.
  • Transaction Management: CREDIT pays money out to the card of an approved payment, not capped by the payment amount, where the payment provider supports it. A credit needs a unique transaction_reference; a repeat returns the first credit.
  • New SIMULATORs category under Payment methods, with the Card Simulator (Simplified Simulator and Simulator, with test cards and metadata controls) and the Payment Simulator (BLIK, EU local methods and Egypt wallets, with their ids and currencies). The method browser on Alternative payments has a matching SIMULATORs tab.
  • New SIMULATOR group under Payouts with the Payout Simulator: payouts to Egypt wallets, UPI and INR, including the mobile_money beneficiary shape.
  • Alternative payments: the E-wallets method now lists the wallets you can offer (Venmo, Cash App, PayPal, Wise and Revolut) and documents options.pay_method, which selects one wallet. Leave it out to let the customer choose. These wallets are pay-in only.

2026-10-15

Added

  • Webhooks says that adding, editing, pausing, resuming and deleting endpoints needs the Manage webhook endpoints permission, and names the three event services as the portal shows them: Transaction processed, Transaction created and Payment method tokenized.

Changed

  • Webhooks says that an endpoint you add in the portal only receives events signed with your merchant key. The events signed with the Qore Payments key (transaction-svc:account:transaction:* and transaction-svc:transaction:full:*) only go to business-account and tenant-level feeds that Qore Payments sets up.

2026-10-14

Added

  • Webhooks now explains how to add, edit, pause, delete and test endpoints yourself in the merchant portal, and what a test delivery is: signed like a real one, marked with X-Webhook-Test: true, never retried, and limited to one per endpoint every 5 seconds (a faster request gets 429 with Retry-After: 5). Endpoint URLs must be public HTTPS; private, loopback, link-local, multicast and reserved addresses (including CGNAT and the NAT64, 6to4 and Teredo IPv6 ranges) are refused and redirects are not followed.
  • Webhooks lists the JWT claims, including exp (5 minutes after iat), and shows how to turn the Base64 DER public key into PEM.
  • New Payment Method Tokenized Webhook page with the real payload and a JSON Schema.
  • Transaction Processed Webhook lists four more events: transaction-svc:transaction:cancelled, transaction-svc:transaction:authorize:cancelled, transaction-svc:transaction:purchase:cancelled and transaction-svc:transaction:session-expired.
  • Transaction Processed Webhook and Payment Method Tokenized Webhook say that new fields can be added to the payload, and that their JSON Schemas accept fields they don't list.
  • Webhooks says which terminal a test sample uses for a terminal, shop or merchant endpoint, and that an endpoint at tenant or account level can't be tested (422).
  • Supported transaction statuses lists REFUNDED (1006), which only a status override sets. A refund through the API creates a separate REFUND transaction and leaves the payment APPROVED.
  • Instalments says that a saved card on the Hosted Payment Page can't be paid in instalments yet, how to build maskedPan so the Embedded Fields saved-card selector works, and that the chosen number isn't passed to the Embedded Fields callbacks.
  • Embedded Fields says that a session without integration_type also offers redirect methods that can't complete there.

Fixed

  • Failed webhook deliveries are retried 3 times, about 1, 2 and 4 seconds apart with each wait varying by up to 50%, and then no further attempts are made. If the attempts take more than 60 seconds together, because the endpoint doesn't answer or answers slowly, the whole delivery starts again, up to 16 attempts in all. Each attempt is limited to 15 seconds in total, including the time your endpoint takes to send its answer. The pages previously said retries continued for up to 24 hours.
  • Webhooks are self-service in the merchant portal. The pages previously said to contact support.
  • transaction-svc:transaction:created is signed with your merchant key, not the Qore Payments key.
  • The Transaction Processed payload no longer lists integration_type, outgoing_amount and outgoing_currency, which are not sent on this payload, and now lists bin_issuer_country. The account-level transaction-svc:account:transaction:* events do carry outgoing_amount and outgoing_currency. status and transaction_type are uppercase, and response_message is the processing code's name, such as TRX_STATUS_APPROVED. On transaction-svc:transaction:created, processing_code and response_message are usually null for a session the customer hasn't paid yet.
  • The tokenized-card webhook example on API Integration now shows the real {event, payload} shape; the payment method ID is payload.payment_method.id.
  • How to read an authorize result: see which of result, action, redirect and form_submit came back, then decide success on result.status (APPROVED, the same as result.approved). processing_code explains a failure. API Integration, Handling Declines and 3D Secure now agree.
  • Response examples leave out the branches that did not fire instead of showing them as null, as the API does. This covers the authorize, payment, payout and OCT references, and Paysafe and BLIK.
  • The authorize request marks only terminal_id, reference, description, currency, amount, transaction_type and payment_method as required. browser_info and return_url are optional, but you should send them with every card payment: when Qore Payments runs 3-D Secure, a payment without browser_info or customer.email ends INVALID with 2000, and without return_url the customer is not returned to your site. The response schema now lists processing_code, response_message and redirect.target. Its status list now has every transaction status: CREATED, PENDING, APPROVED, DECLINED, CANCELED, INVALID, SESSION_EXPIRED and REFUNDED. ERROR, which the API never returns, is gone, so regenerate any client built from the spec.
  • Embedded Fields says that country in the session request does not change the payment methods offered.
  • Hosted Payment Page explains how to confirm the final status: the session_id is the transaction ID. A retried payment's parent_id is the attempt it retries, so follow the chain back to the session_id; Embedded Fields says the same.
  • Apple Pay and Google Pay Wallet Redirect are not available on Embedded Fields. Wallet Redirect, Apple Pay and the Payment methods page previously listed it, and the wallet authorize response example now has the real shape.
  • Interac and Open Banking Bank Redirect are not available on Embedded Fields either, because Embedded Fields does not follow a redirect. Bank Redirect previously described an Embedded Fields flow.
  • reference is at most 40 characters on the payment and payout routes too. Payments, Payments – Direct API Integration and the payment and payout API references previously said 80.
  • Transaction Processed Webhook says that the three pending events are not sent for real transactions today: a pending transaction's next webhook is the event for its final status.
  • The simulator request examples on Cards and 3D Secure use the real payment_method.data fields.
  • The OpenSSL encryption example in the authorize API reference uses RSA-OAEP with SHA-256, which the API expects, instead of PKCS#1 v1.5.
  • The Node.js webhook example on Transaction Management converts the public key to PEM and accepts only RS256.
  • Encryption Example explains that the Qore Payments Embedded Fields and Hosted Payment Page receive the public key by design, and that your own browser code should not encrypt card data.
  • Masked card numbers in the examples start with an 8-digit BIN, for example 41111111-******-1111, as the gateway now masks a card number of 16 or more digits. This covers API Integration, Transaction Processed Webhook and the authorize and OCT references.
  • response_message is the processing code's name, for example RISK_FAILED_FRAUD for 4101. Handling Declines and Transaction Processed Webhook previously paired it with 1000.
  • An INVALID transaction always carries a processing code (2xxx, or 1001). Handling Declines previously said it could have none; a request rejected before a transaction exists gets HTTP 422 instead.
  • options.number_of_instalments on the Hosted Payment Page: don't send it. If you do, webhooks report it even when the cardholder pays in full, and a value your terminal doesn't allow makes the payment INVALID with 2000. Instalments and Transaction Processed Webhook say the same.

2026-10-13

Added

  • New Instalments page. It covers:
    • how cardholders split a card payment into instalments in the card form of Embedded Fields and the Hosted Payment Page;
    • when the selector is available and what the cardholder sees;
    • how to read the chosen number from the number_of_instalments webhook field.
  • Transaction Processed Webhook now lists payload.number_of_instalments.
  • Embedded Fields and Hosted Payment Page now describe the instalment selector and link to the new page.

Fixed

  • Embedded Fields now documents the real session request. A session created as previously documented was rejected with HTTP 400:
    • return_url does not exist and has been removed.
    • The required success_url, cancel_url and error_url are now in the example request, the example response and the parameter table.
    • integration_type is documented. Send "EMBEDDED_FIELDS"; without it, the session is recorded as DIRECT_API, and that fallback will be removed.
    • The optional metadata, tokenization and customer_ip fields are now listed.
  • The /api/sessions example on Hosted Payment Page now sends success_url, cancel_url and error_url instead of return_url.
  • Hosted Payment Page said options.number_of_instalments offers instalments for the payment. It doesn't: the field doesn't request instalments from the acquirer. The cardholder chooses the number in the page's selector.

2026-09-30

Fixed

  • Webhooks now says the SHA-512 digest is lowercase hex of the raw request body, and a new "Which key signs a webhook" section lists which events are signed with your merchant key and which with the Qore Payments key, and how the JWT's sub claim tells them apart. The page previously said every transaction-related event used the merchant key.
  • On phones, the menu now opens over the whole screen, so its last items are no longer cut off at the bottom, and the current tab is listed like the others.
  • Overview and Obtain Access Token now show the real token lifetime: 300 seconds on UAT and 60 seconds in production. They previously showed 3600. Read expires_in from each token response rather than hard-coding it.

Changed

  • The empty Transaction API overview page now redirects to Transaction Status API.
  • The webhook verification flow on Webhooks is now a short sequence diagram in the same style as the other diagrams.
  • The transaction lifecycle on Supported transaction statuses is redrawn: it reads left to right from CREATED, the five final statuses are grouped on the right, each status is in its colour and a legend explains them. The "Transaction Transition Rules" diagram, which showed the same transitions, is folded into it.

2026-09-29

Fixed

2026-09-28

Changed

  • New design for every documentation site. It has a one-row header with the tabs and search (open it with ⌘K or Ctrl K), and code samples sit in dark panels with a language bar and a copy button. Tables, callouts, status values, sequence diagrams and API reference blocks are restyled to match; diagrams now colour each participant by who runs it and carry a legend. Each site keeps its own brand colours, typeface and logo.
  • Dark mode on every site. It follows the system setting, and the button in the header switches it.
  • Pages no longer have a left navigation or an "On this page" column, so text, code samples and diagrams use the full width. Instead, a bar at the top of every page lists the sections of the current tab, with links to the pages of the current section. On phones the menu still lists every page. Diagrams now span the text column.
  • Headings, tables and notes no longer carry icons, and headings no longer show the ¶ link beside them. Links to sections still work as before.
  • Navigation regrouped into six tabs that follow an integration from start to finish: Get started, Integrate, Payment methods, Payouts, Operate and Changelog. Payment methods groups its pages into Alternative, Cards, Wallets and Redirects, the same categories as its method browser. Every page keeps its address.
  • New landing sections at the top of Overview, Hosted Payment Page, Embedded Fields, API Integration, Alternative payments, Non-card Payouts and Transaction Management. They cover who does what in the flow, an interactive preview of what the customer sees, the steps with code in cURL and Node.js, and where to go next. The existing content of each page follows unchanged.
  • Every other page now opens with its own hero, including every payment method, payout and operations page, the Get started pages and this changelog. It states what the page helps you do, gives a short summary and links to the page's key sections. Most heroes also show who does what, the test values or the environment URLs.
  • Alternative payments now opens with a Payment methods browser.
    • It replaces "Choose a method", "Create a payment" and the "More payment methods" links.
    • Pick Alternative, Cards, Wallets or Redirects to see each of its methods in turn: how it works, its fields and a request example. The Jump to links scroll to a method on the page, or open the category's other pages.
    • Cards also has a Test tab with the test cards and simulated 3DS flows.
    • A new Processing flows section shows the Payments and OCT flows.

  • Sequence diagrams are redrawn on every page:

    • numbered steps;
    • "IF" and "OR" branches;
    • step banners;
    • a legend that tells requests from responses.

    Their text can now be selected and found with the browser's search. - Every landing page's code panel shows the endpoint in its header. The second hero button jumps to a section on the same page. Each landing page ends with links to the previous and next tab and to its API reference. - Moving between pages no longer reloads the whole site, and pages, buttons, tabs, switches and previews animate as they change. Clicking a card, button or link that opens another page first scrolls smoothly back to the top, and Back returns to where you were. The tabs and Jump to links at the top of a page, and in the Payment methods browser, open the next page without scrolling. You stay at its hero, which describes the page you picked, or at its content if you had scrolled past the hero. On wide screens, hero bands with a diagram share one height, so the tabs below them stay in place as you switch pages. Movement is left out when the operating system asks for reduced motion. - llms.txt and llms-full.txt follow the new navigation and now also list the Authentication Simulator and Account Funding Transactions pages. llms-full.txt includes each landing page's summary and fills in the brand's hosts and URLs in code samples.

Fixed

  • The links to "Saving Cards for Future Payments" and "Creating a Customer" on API Integration now open those sections.
  • The Transaction Status API link on Neogated (BLIK) now opens the Transaction Status API page.
  • A missing page now shows a "Page not found" message with links back to the overview and the changelog.
  • The flow diagram in the 3D Secure card payment recipe now numbers every step and shows the full request-authentication path.

2026-09-16

Added

  • New optional originator_url request field on Authorize, Payments, Hosted Payment Page and the Embedded Fields session request: the URL of the website or page on which the customer started the purchase. It must be an http/https URL (a # fragment is allowed); if omitted or empty, the website configured on the terminal is used. The value stays on the transaction when it is retried or routed to another payment provider, and is forwarded to providers that require the originating website.

2026-09-15

Added

  • New Deleting a Saved Card section on the API Integration page, documenting DELETE /api/payment-methods/{payment_method_id} — the previously undocumented endpoint for removing a stored card. It covers the required payment_method:detach permission, the 200 response carrying the payment method with status: "DELETED", the fact that the call is idempotent and needs no Idempotency-Key, and the 403 and 422 responses.
  • An explanation of what deletion actually does: the card can no longer be charged, it is removed from the customer, the record is retained and still retrievable as DELETED for reconciliation and disputes, and the deletion cannot be undone. Permanent erasure of the stored card data (for example a GDPR erasure request) is noted as a separate operation handled through support.
  • Guidance on implementing a "remove card" action in a merchant application: the call carries merchant API credentials and must be made from the merchant backend, never from a client application — the publishable client key cannot delete payment methods.
  • New Charging a Deleted Card error case, showing the INVALID_REQUEST_PAYMENT_METHOD_INACTIVE rejection returned when a transaction references a deleted payment method, and Workflow 3: Customer Removes a Saved Card.

2026-08-28

Removed

  • The Paydor and Kynta documentation sites have been retired. docs.paydor.com and docs.kynta.com are no longer built or published, and all Paydor- and Kynta-specific environment values, endpoints and examples have been removed from the documentation.

2026-08-27

Added

  • New Altitude Pay documentation site at https://docs.altitudepay.solutions, carrying the Altitude Pay brand — logo, favicon, the Altitude violet accent and the Figtree typeface, matching the Altitude Pay dashboard and login page.
  • Altitude Pay environment values on the Environments page: the UAT and Production OIDC Token URLs (realms qore-uat and qore-prod, shared with the Qore Payments platform) and API URLs.
  • Altitude Pay endpoints across the rest of the documentation — the token and session endpoints and the embedded-fields.js script tag on Embedded Fields, the challenge notification URLs on 3D Secure, the base URLs on Transaction Management, the Google Pay request example and gateway identifier on Google Pay, and the llms.txt URLs on AI-Assisted Integration.

Fixed

  • The example token request on the Hosted Payment Page page no longer shows one specific brand's UAT authentication host in its comment; it now points to the Environments page for the OIDC Token URL of your own environment.

2026-08-20

Added

  • New Adhere to Google policies step in Activation Prerequisites on the Google Pay page, linking both the Google Pay and Wallet API Acceptable Use Policy and the Google Pay API Terms of Service. Previously only the Acceptable Use Policy was referenced.
  • New explanation of the Google Pay gateway integration type in Google Pay API Configuration, stating that the Payment Gateway performs all token decryption on the merchant's behalf, and describing how to set gateway and gatewayMerchantId in the tokenizationSpecification object, with a link to Google's gateway ID reference.
  • New Apple Pay page, giving Apple Pay its own entry under References. It covers Apple Pay tokenization (DPAN, cryptogram, ECI) and why Apple Pay is treated as a fully authenticated CRYPTOGRAM_3DS transaction, Apple's branding and acceptable-use obligations, activation prerequisites, the supported card brands, and the two available integration methods — Wallet Redirect where the PSP renders the Apple Pay sheet, and Network Token for merchants who decrypt the PKPaymentToken themselves.

Changed

Fixed

  • Corrected the Hosted Payment Page request contract: the required return_url field did not exist and has been replaced with the three actual required redirect fields, success_url, cancel_url and error_url; description is now listed as required (1–100 characters); reference is documented as capped at 40 characters; and the previously undocumented language field and options object (number_of_instalments, skip_three_ds, cvv_less) have been added. The "Backend Setup" section now notes that its example targets the separate /api/sessions endpoint used by Embedded Fields, not /api/hosted-payment-page.
  • Fixed incorrect Keycloak realm names on the Embedded Fields page for Paydor, Kynta and Qore Payments, which previously pointed to Finrelay's uat/production realms instead of each brand's own realm (paydor-uat/paydor-prod, kynta-uat/kynta-prod, qore-uat/qore-prod).
  • Fixed the same realm mismatch in the Production rows for Paydor and Kynta on the Environments page.
  • build-all.ps1 now builds the Qore Payments site and generates its llms.txt; it previously only built Finrelay, Paydor, Kynta and AdriaPay.

2026-09-06

Added

  • New Bank Redirect (Interac & Open Banking) page documenting the interac-redirect and openbanking-redirect payment method types. It covers the Hosted Payment Page, Embedded Fields and Direct API flows, the embedded-fields stub script keys, and flow diagrams for both the HPP and API paths. It states that both run on the payment transaction type — the terminal needs TRX_TYPE_PAYMENT and they are initiated through POST /api/transactions/payment, not the card authorize endpoint.
  • The Bank Redirect page states that the outcome is asynchronous: authorize always returns PENDING, the transaction-processed webhook is the source of truth, and a payment the customer abandons is not cancelled automatically — it stays PENDING until the bank reports an outcome, so the Transaction Status API should be used to check where it stands.
  • Documented the limitations of both methods: purchase only, no stored payment method or recurring use, and no 3-D Secure step — the customer's bank performs its own authentication.

2026-08-19

Added

  • New Billing Address section on the Google Pay page, explaining how to request a billing address via billingAddressRequired and billingAddressParameters in the Google Pay API request, with a request example and a link to Google's BillingAddressParameters reference.
  • New Google Pay branding note on the Google Pay page: merchants offering Google Pay must use the official Google Pay logo and button assets in compliance with the Google Pay Android and web brand guidelines, without modifications to asset colors, proportions, or appearance.

Changed

  • The Google Pay introduction now uses Google's standard description — Google Pay™ lets users pay with their cards stored in their Google Account — and the page title carries the ™ mark.

2026-08-13

Added

  • New Supported Languages section on the Hosted Payment Page page. It lists the four available languages, explains how to set the default language per merchant in the Merchant Portal (Accounts → Merchants → Hosted Payment Page customizations → Language), covers the language selector customers can use on the payment page, and documents the fallback to English.
  • Added Romanian (ro-RO) and Swedish (sv-SE) to the Supported Locales table for Embedded Fields.
  • New Initialization Options table on the Embedded Fields page, documenting clientKey, sessionId, environment and locale. Previously these were only shown inline in code samples. Notes that when locale is omitted the customer's browser language is used if it is supported, otherwise English.

Changed

  • The Customization section on the Hosted Payment Page page now names the available customizations, including the display language, and links to the new Supported Languages section.

2026-06-11

Added

  • New Simplified Authentication Simulator reference page under 3D Secure, documenting the test-card-driven 3DS simulator (frictionless, interactive redirect approve/decline, form-submit authenticated/declined, and frictionless-authenticated-with-insufficient-funds) and the metadata escape hatch for unmapped cards.

Changed

  • Made the Simplified Authentication Simulator the default, recommended option for testing 3DS. The 3D Secure page and the 3DS Card Payment recipe now lead with the test cards and reframe the metadata-driven simulated_flow simulator as the advanced option.

2026-06-02

Added

  • Added iDEAL (paysafe-redirect-idl) to the Paysafe Redirect Supported Payment Methods list and the Direct API Integration examples, and added paysafe-redirect-idl to the Paysafe Redirect authorize OpenAPI schema.

Fixed

  • Added the missing PaySafe Wallet (paysafe-redirect-wlt) code to the Paysafe Redirect authorize OpenAPI schema so the payment_method.type enum matches the documented Supported Payment Methods list.
  • Corrected an invalid payment method code in the Paysafe Redirect authorize OpenAPI response example (paysafe-redirect-pcs → paysafe-redirect-psc, PaySafeCard).

2026-05-26

Fixed

  • Corrected the Qore Payments production OIDC realm in Environments from production to qore-prod.

2026-05-20

Added

  • Added a Supported Transaction Types section to the Transaction Management page, listing all initial transaction types (PURCHASE, AUTHORIZE, OCT, PAYOUT, PAYMENT) and management transaction types (CAPTURE, REFUND, VOID) with descriptions.

Changed

2026-05-18

Changed

2026-05-15

Added

  • New Wallet Redirect (Google Pay & Apple Pay) reference page covering the google-pay-redirect and apple-pay-redirect payment method types: how the PSP-hosted wallet flow works, HPP / Embedded Fields / Direct API behavior, the authorize request and response shape, and how it differs from the native Google Pay integration.

2026-05-12

Changed

  • Updated the Direct API Integration request schema: description, country, customer_ip, return_url, error_url, and cancel_url are now required. Added the new error_url and cancel_url fields for redirecting the customer after failed or canceled payments (previously a single return_url covered all outcomes).

2026-04-27

Added

  • New API Integration Guidelines page in Getting Started covering recommended request hygiene (mandatory User-Agent header, HTTPS, correct Content-Type, clean payloads) and how to troubleshoot a 403 with an empty response body.

Changed

  • Documented the required recipient customer fields on the OCT request: first_name, last_name, email, phone, address, city, country, and postal_code are all required. Added a Customer Fields table with field-level notes (E.164 phone format, ISO 3166-1 alpha-2 country code) and a JSON example, and updated the OCT OpenAPI schema to mark these fields as required.

2026-04-24

Added

  • Documented the optional customer_ip field on the card Authorize request. Pass the end customer's IPv4/IPv6 address so fraud and 3DS risk checks see their IP rather than your backend's; if omitted, the gateway falls back to the IP of the incoming HTTP request

Changed

  • Aligned the customer_ip description on the Payments, Payouts, and OCT request schemas with the Authorize page — noting IPv4/IPv6 support, the fallback to the HTTP request IP, and when to set it explicitly

2026-04-23

Added

  • Added field format requirements table to the Encryption Example page, documenting accepted plain-text formats for card number, CVV, expiration month, and expiration year before encryption.
  • Added Card Payment Data Fields reference table to the API Integration page.

Changed

  • Clarified that encrypted_expiration_year accepts both 2-digit (26) and 4-digit (2026) year formats in the Encryption Example page, API Integration page, and OpenAPI spec.
  • Clarified phone / customer_phone_number field descriptions across Embedded Fields, Hosted Payment Page, and Neogated Direct API Integration pages: phone numbers must be in E.164 format (e.g., +12125551234) and are validated using Google libphonenumber's isPossibleNumber check, which verifies the number is a plausible length for its country code.

2026-04-21

Changed

  • Environments page now shows the complete OIDC token URL (e.g. https://auth.example.com/realms/production/protocol/openid-connect/token) instead of separate OIDC URL and Realm fields, and groups UAT and Production values into distinct sections for easier reference

2026-04-20

Changed

  • Moved Handling Declines into its own subsection under References (at references/handling-declines/index.html)

Added

  • Added Handling Declines reference page documenting the full list of processing_code values returned by the gateway (families 0xxx, 1xxx, 2xxx, 3xxx, 4xxx), the distinction between gateway-normalized fields (processing_code, response_message) and raw PSP fields (payment_provider_response_code, payment_provider_response_message), and recommended retry/handling behavior per code family

2026-04-17

Added

  • Account Funding Transaction (AFT) documentation — how to include options.funding parameters for VISA and Mastercard funding transactions on PURCHASE and AUTHORIZE
  • Documented custom 3DS challenge notification URL (options.three_ds.notification_url) for Direct API integrations, including validation rules, the ACS callback flow, and the required authentication-completed follow-up call

2026-04-16

Added

  • Added payment_method_expiry field to the Transaction Processed Webhook — an ISO-8601 date representing the last day of the payment method's expiry month (e.g., 2027-12-31), nullable
  • Added AI-Assisted Integration page under Getting Started with brand-specific llms.txt and llms-full.txt URLs and usage examples for Claude, Cursor, GitHub Copilot, and other AI tools
  • Added <link rel="alternate"> meta tags to every page's <head> for automatic discovery of llms.txt and llms-full.txt by AI agents and crawlers
  • Added tip callout on the homepage pointing to the AI-Assisted Integration page

2026-04-15

Added

  • New Recipes section with step-by-step 3DS card payment integration guide
  • Encryption example now includes Node.js and Java examples (runnable single-file snippets)
  • Access token example in recipe includes curl, Node.js, and Java tabs
  • Introduced documentation changelog

Fixed

  • Fixed redirect URLs for 3DS authentication flows

2026-04-13

Added

  • Simulator documentation for card and 3DS flows

2026-04-10

Changed

  • Removed x-api-key from hosted payment page docs

2026-04-08

Fixed

  • Corrected maximum retry limits for 3DS authentication

Added

  • Documentation for 3DS fallback behavior and repeated authentication

2026-04-01

Fixed

  • Use exact 3DS action type values (THREE_DS_2_FINGERPRINT, THREE_DS_2_CHALLENGE)

2026-03-31

Changed

  • Replaced /api/oauth2/login/token with OIDC client credentials in HPP example

Added

  • Payment (deposit) documentation
  • 3D Secure integration documentation

2026-03-19

Added

  • Payout documentation with INR bank transfer support
  • Google Pay integration docs and PDF generation

Changed

  • Added integration type limitation warning to OCT docs
  • Added note that HPP and Embedded Fields are not supported for OCT transactions
  • Added note that HPP and Embedded Fields are not supported for payouts
  • Removed /api/token endpoints from docs

Fixed

  • Removed {.md-button} from Google Pay PDF download link
  • Added pymdownx.emoji extension for Material icon rendering

2026-03-16

Added

  • Neogated (BLIK) payment method documentation
  • Google Pay integration documentation

2026-03-13

Added

  • OCT (Original Credit Transaction) documentation

2026-03-08

Fixed

  • Updated submitPayment customer postal code field from zip to postalCode

2026-03-04

Added

  • Network Token payment method documentation

Changed

  • Updated Network Token docs for ECI and source field changes

Fixed

  • Removed erroneous redirect for API integration page

2026-01-29

Changed

  • Updated Embedded Fields documentation with brand-specific initialization notes, component types, lifecycle management, and supported locales

2026-01-13

Changed

  • Updated Embedded Fields documentation with current integration details

2026-01-12

Added

  • Field Configuration documentation for Embedded Fields

2025-11-10

Added

  • Support for return_url_target parameter in Paysafe redirect

2025-10-21

Added

  • API integration documentation for card tokenization and saved cards

2025-10-20

Added

  • Documentation for saving and using saved cards in HPP

Changed

  • Updated tokenization requirements and customer_id behavior

2025-10-15 — Initial version

Added

  • Initial documentation import