PayConexDecryptxShieldConexTECS Platform
Release Notes
Request SandboxContact Us
Back to All

PayConex - 07.14.2026

2 days ago by Ryan Cox

In this release, we’ve introduced updates and enhancements across the PayConex platform—focused on 3-D Secure and hosted payment flexibility, POI and BluePOS capabilities, Account Updater and tokenization improvements, configurable duplicate-transaction handling, and a broad set of processor, settlement, and reporting fixes informed by merchant and support feedback. Below is a summary of what’s included.

Key Updates and Enhancements

3-D Secure and hosted payments

  • Configurable 3-D Secure challenge behavior on hosted payment forms. Merchants can now choose how 3-D Secure challenges are handled during checkout when 3-D Secure 2.2 is enabled, allowing a better balance between fraud protection, liability shift, and customer experience.
  • CAD currency support for 3-D Secure. Canadian merchants can now use CAD with V4 3-D Secure endpoints for authentication and liability-shift flows without workarounds.
  • ACH field controls in the Checkout Component. The Checkout Component and PayConex configuration UI now honor existing ACH field toggles, giving integrators control over which ACH inputs appear and whether they are required when ACH is selected.
  • Google Pay initialization improvements. Resolved an issue where including email or phone in a Google Pay iframe initialization could cause an error when those fields were disabled in googleSettings. The flow now handles this configuration more gracefully.

Checkout Component APIs

  • Sorting and filtering for Checkout Component configurations. The GET /api/v4/accounts/{accountId}/payment-iframe endpoint now supports sort and filter parameters, making it easier to locate and manage Checkout Component configurations at scale.
  • ACH token support on the token-data endpoint. The /api/v4/accounts/{accountId}/token-data/{bfTokenReference} endpoint now supports ACH tokens, allowing integrators to retrieve stored ACH details through the same API used for card tokens.
  • Bearer token compatibility across API endpoints. Fixed an authentication issue where bearer tokens generated by the init endpoint could fail on newer Go-based API endpoints (such as token-data), restoring consistent access across the V4 API surface.

Security and access controls

  • Email-based two-step verification. PayConex now supports email-based 2-step verification as an alternative to app-based 2FA. Administrators can configure app-based and/or email-based verification independently, providing a secure option in environments where mobile authenticator apps may not be permitted.
  • “Allow Credits” restricted to Risk Admin users. The ability to enable or disable credit transactions on an account is now limited to Risk Admin users, strengthening control over high-risk account settings.
  • API key scope protection. API keys that include private or enhanced scopes (such as POI and iFrame scopes) can no longer be edited through the PayConex UI in a way that would silently remove those scopes. This prevents accidental loss of integration capabilities when updating key settings.

Account Updater and tokenization

  • List Account Updater subscriptions endpoint. A new API endpoint allows merchants to retrieve all Account Updater subscriptions on their account, including subscription status, period information, and merchant-defined identifiers—supporting reconciliation, auditing, and enrollment tracking.
  • CardSync token expiry handling. Fixed an issue where BFTokens created through CardSync could be missing expiry information, improving token data completeness for downstream processing.
  • Improved reissue traceability. Reissue-related activity is now more fully traceable across payment tokens and transactions, giving support and operations teams better visibility into the lifecycle and origin of reissued transactions.
  • Consistent BFToken behavior for reissues. Reissue transactions now consistently use BFToken handling without reliance on a legacy feature toggle, simplifying behavior for integrators.

POI, BluePOS, and device integrations

  • Expanded WebSocket response fields for BluePOS. V4 WebSocket responses now include additional required card and EMV fields (such as tenderType, cardBrand, and bin), improving receipt rendering and downstream processing for BluePOS integrators.
  • Enhanced POI show-dialog API. The POI show-dialog endpoint now supports optional body content, styling configuration, and signature capture requirements—enabling richer, more flexible on-terminal dialogs without custom client-side logic.
  • Multiple merchants per terminal. POI endpoints now accept an optional mmId parameter, allowing a single terminal to process transactions for multiple merchant accounts.
  • Receipt reprint via POI API. Integrators can now request receipt reprints on BluePOS terminals through a new POI receipt-print endpoint, supporting customer or merchant copy reprints without manual device intervention.
  • Ingenico Lane 3000 device profile. Added support for the Ingenico Lane 3000 as a recognized device profile, enabling consistent configuration and use of this terminal model across the platform.
  • Clearer credit-transaction errors. When credit transactions are disabled on an account, device credit requests now return a clear, actionable error message instead of a generic authorization failure.

Configurable duplicate external transaction ID handling

PayConex now offers account-level configuration for how V4 payment endpoints handle duplicate ext_transaction_id (also known as extTransactionId for v4 API) values:

  • Blocking mode (default). Duplicate external transaction IDs are rejected by default, including for newly created accounts.
  • Idempotent success mode. Merchants can optionally configure PayConex to return the original successful response when a duplicate ID is submitted, without re-running the payment.
  • Conditional replay mode. An additional option returns the original successful transaction on duplicate submission, but automatically retries the payment if the prior attempt declined or errored—supporting idempotent success handling while still allowing recovery from failed attempts.

RapidConnect, PTS, and processor improvements

We’ve delivered a set of processor-focused updates across RapidConnect and RapidConnect-North

  • PIN-less debit support for RapidConnect-North. The gateway now supports PIN-less debit routing for RapidConnect PTS, applying AID-based tender-type logic consistent with legacy RapidConnect behavior.
  • EMV TLV filtering for RapidConnect PTS. EMV TLV data sent to RapidConnect PTS is now filtered to include only processor-supported tags, reducing “Error parsing DLV sub-message” failures and improving approval rates for valid EMV transactions.
  • Asynchronous RapidConnect timeout reversals. RapidConnect timeout reversals are now processed asynchronously via a queue-based mechanism, allowing API responses to return within timeout limits while still meeting processor retry requirements.
  • RapidConnect-North retail EMV authorization. PayConex now handles retail EMV transaction authorizations correctly for merchants using RapidConnect-North as their card processor.
  • RapidConnect-North descriptor phone number correction. Fixed an issue where RapidConnect-North could source descriptor phone numbers from an incorrect backend table after account migration, causing wrong phone numbers to appear on cardholder statements. Descriptor phone numbers now come from the correct configuration source.
  • RapidConnect-North EMV settlement. Improved PTS EMV settlement file generation to meet processor specifications.
  • Legacy RapidConnect certification cleanup. Removed the obsolete RBL006 RapidConnect code path and ensured delayed refunds use the account’s active RapidConnect certification (e.g., RBL018).
  • Payment endpoint routing improvements. Payment transaction endpoints now route requests based on processor at runtime, continuing to support incremental platform modernization without changing external API behavior.

Settlement and batch processing

  • V4 device-store settlement correction. Fixed an issue where V4 device-store transactions were incorrectly included in settlement when they should remain unsettled.
  • Elavon clearing file ID uniqueness. Resolved a race condition where concurrent clearing file creation could produce duplicate file_id values, improving settlement file integrity.
  • FIS batch duplicate entry prevention. Fixed an issue where multiple entries could exist in batch tables for the same FIS batch number.

Reporting and portal experience

  • Site-specific portal UI redirects. Users accessing PayConex through a site-specific hostname now remain on the correct site-specific routing path through portal redirects and backend API communication.
  • Reporting query performance. Added ordered composite indexes on key transaction time fields to improve filtering and sorting performance for large transaction datasets.

Bug Fixes

Transaction processing and integrations

  • Same-day refunds after AVS-decline reversals. Fixed an issue where same-day refunds could fail after an automatic reversal was triggered by the AVS-decline mechanism, even when the original sale appeared approved to the merchant.
  • QSAPI reissue card brand consistency. When a reissue is submitted with a different card than the original tokenized transaction, response fields such as card_brand now correctly reflect the new card rather than returning inconsistent data from the original transaction.
  • QSAPI CVV2 with BFID. Resolved an issue where cvv2 was not returned on QSAPI transactions when a BFID was used in the request.
  • ShieldConex BFID-only QSAPI payments. Restored the BFID-only payment workflow in QSAPI, where PayConex reads and detokenizes token data server-side without requiring callers to include scx_token_* fields directly.
  • CardSync subscription creation with billing address. Fixed an error when creating a CardSync subscription from a V4 transaction that included customer and billing address data.
  • Click to Pay error handling. Improved error handling for Mastercard Click to Pay checkout failures (including 503 responses), reducing unnecessary alert emails and providing clearer diagnostic information.
  • Ingenico keyed transactions with track data. Ingenico devices can return track data even when entryMode is KEYED; these transactions are no longer incorrectly rejected with a “Keyed transactions cannot contain track data” validation error.
  • Gateway error message typo. Corrected a typo in a gateway error message (“Tender typs is invalid” → “Tender type is invalid”).

PayConex UI and transaction details

  • Transaction details for settled transactions. Fixed an issue where the transaction details page displayed “That Transaction ID was not found” for valid, settled transactions when accessed from search results.
  • V4 capture original authorization timestamp. V4 capture transactions now correctly display the timestamp of the original V4 authorization.
  • Failed device transactions in transaction history. Failed device transactions (such as those with processor format errors) now appear correctly in the PayConex transaction history UI.
  • EBT data on POI SALE requests. Fixed an issue where the EBT object was not passed through to the device-sale endpoint when submitted via the POI SALE endpoint, preventing EBT data from reaching the BluePOS application.

Reporting, exports, and batch reports

  • Card and ACH batch reports. Fixed an issue where Card and ACH batch report pages loaded but displayed no data due to a missing report file reference.
  • Transaction and reporting filters. Resolved multiple reporting filter errors, including invalid transaction type filters, trace tag search issues, and edge cases with very large transaction IDs.
  • CSV export column alignment. Fixed an issue where downloaded CSV exports placed data in the wrong columns (shifted one column to the right), affecting fields such as Network ID and HSA data.

We appreciate your feedback and continued support. If you encounter any issues or have questions regarding this release, please contact our customer service team at [email protected].