Skip to content

Changelog

Track every change to the Finrelay 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-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 Finrelay 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