UP Gateways Release 2026.10.808

2026-10-20T00:00:00Z

⚠ Breaking changes11 changes may need action on your side

AuthCapture IDs and follow-up errors have changed
Batch file access now needs specific permissions
Merchant contact details now reject invalid email and phone formats
User lists now show only your own scope
User lookup and changes now respect account scope
Merchant credentials can no longer read other merchants' names
User creation and updates now enforce role and reseller checks
Wallet registration reads are now access-limited
Settlement run-state now requires MerchantId and RunId
Wallets no longer collect shipping addresses in locked sessions
API reference now shows the correct response content types

New in this release

Hosted payment page

The Hosted Payment Page now supports shopper-selected carrier shipping rates, and wallet-based shipping flows are more accurate when shipping is locked or already chosen.
Hosted payment sessions now carry enhanced invoice and Level 3 data more consistently, including through cloned payment links, helping merchants send richer order details with payments.
The Hosted Payment Page has several usability and security fixes, including better wallet button sizing, correct 3-D Secure challenge behavior, safer host/origin handling, and tighter access checks when reading hosted payment sessions.

Virtual Terminal

The Virtual Terminal now supports more transaction details, including register selection, duplicate-check waiver, soft descriptor, notes, and tags.
Virtual Terminal workflows are faster for assisted payments, with split tenders planned up front, quick-fill from recent transactions, and support for charging a vaulted card using its CVV alias.
The Virtual Terminal experience has been polished with clearer inline errors, better keyboard and tablet support, accessibility improvements, BIN badges, and more reliable focus behavior.

Fraud controls and security

Transaction screening now supports more rule types, including per-card, per-device, IP, email, decline-rate, country, and time-of-day checks, with local holds and better handling of retry and repeat declines.
Merchants can now test proposed screening rules against recent transactions before saving them, and settings errors are clearer when a rule prevents a save.
The platform adds stronger protection for sensitive data and suspicious activity, including card-testing attack detection with merchant alerts, encrypted handling for uploaded batch card data, and clearing sensitive card authentication data from outbound responses.

Transaction operations and settlement

Transaction Explorer now gives a fuller view of settlement and approval activity, including partial approvals, all settlement statuses in filters, and a settlement remediation queue for retrying affected batches.
Split-tender and ACH follow-up handling is more complete, including recording ACH returns that leave a completed split-tender group short.
The v1 API facade now handles AuthCapture and follow-up transactions more cleanly, returning clearer validation errors instead of retry-style failures when a void, reversal, refund, or capture is not allowed.

Back-office reporting and workflows

Contract management now supports bulk operations, CSV import, and change history, making large contract updates easier to manage.
Report exports now download over standard HTTP instead of relying on a live admin session, improving reliability for larger exports.
Batch file and contract workflows received reliability improvements, including clearer batch failure reasons, a working contract import file picker, and support for an optional example row during import.

Admin UI and dashboards

Grids across the admin UI now have a more capable filtering experience, with an All filters drawer, collapsible filter cards, better range controls, clearer validation, and improved handling of saved or refused filters.
Transaction and dashboard views now include optional stat panels and threshold indicators, helping users spot trends and breaches more quickly.
The admin experience also includes a range of usability fixes, including clearer settings save messages, better dark-mode behavior, improved responsive grids, more readable technical error details, and IP geolocation shown where IP addresses appear.

Developer portal and API reference

The API reference now shows richer operation details, including accurate response media types, examples, enum members, nested fields, model pages, required scopes, and published request examples on operation pages.
The Try-It and playground tools are more useful for sandbox testing, with selectable outcomes, operation-aware outcome choices, a hosted page playground, and an embed SDK playground in the developer portal.
Request logging and webhook troubleshooting are easier, with better request-log filtering, the ability to open a request in the console and copy it as code, a webhook event page, and event-based filtering in delivery history.

Access controls and data handling

Several merchant, user, wallet, and hosted-session reads are now more tightly scoped so users only see records they are allowed to access.
Sensitive configuration values are better protected in admin responses, including hidden login client secrets and hidden encrypted DNS provider credentials.
Contact and company details now validate more consistently, including merchant contact email, phone, and fax fields, plus normalized company website URLs across merchants, customers, and resellers.

⚠ Breaking changes

The changes below may need action on your side.

Breaking AuthCapture IDs and follow-up errors have changed

What changed: AuthCapture now returns the original authorization's TransactionId, and its TransactionType is AuthCapture. An AuthCapture with a TotalAmount different from the authorized amount is now refused with HTTP 400 and RC 1007, with nothing captured; a Void, Reversal, or linked Refund that the original transaction no longer allows now returns HTTP 400 and RC 1005 instead of HTTP 500 and RC 1000.

Who is affected: This affects anyone who uses AuthCapture or sends Void, Reversal, or linked Refund requests against earlier transactions. It is especially relevant if your integration stores transaction IDs, checks transaction types, matches on response codes, or retries failed follow-up requests.

What you need to do: Read the AuthCapture ID as the captured authorization's TransactionId, and send the authorized amount as TotalAmount. Update your error handling to treat RC 1005 as final and do not retry it; handle RC 1007 for AuthCapture amount mismatches.

Breaking Batch file access now needs specific permissions

What changed: Batch file endpoints now require Transactions.BatchFiles permissions for viewing, uploading, processing, downloading, and deleting. Batch file responses and results exports now mask card numbers to the last four digits, Transactions[].RawData is always null, and GET /api/transactions/batch-file/{id}/download now returns stored CSV lines (TransactionType,Amount,CardNumber,CustomerName) instead of the original uploaded file.

Who is affected: This affects anyone using batch file routes, especially users, API keys, or custom roles that do not already have the required batch file permissions. It also affects integrations that read full card numbers, use Transactions[].RawData, download the original uploaded file, or upload for merchants outside the caller's scope.

What you need to do: Grant the needed Transactions.BatchFiles permissions if you use custom roles, per-user grants, or API keys tied to custom roles. If your integration processes batch file data, update it to use masked card numbers, read the row fields, match rows by line number, keep your own copy of files you may need to resubmit, and upload under a principal scoped to the target merchant.

Breaking Merchant contact details now reject invalid email and phone formats

What changed: Merchant create and update now return HTTP 400 if contact email, phone, or fax is malformed. This applies in the native API, the portal, and the v1 API facade; blank values are still accepted.

Who is affected: Anyone who creates or updates merchants through the API or portal is affected. Existing merchants with invalid stored contact email, phone, or fax cannot be saved again until those values are corrected or cleared.

What you need to do: Send a valid email address, phone number, or fax number, or leave the field blank. Correct or clear any existing invalid merchant contact email, phone, or fax before saving those merchants again.

Breaking User lists now show only your own scope

What changed: When merchant and reseller users list users through GET /api/identity/users, or export the user list to Excel or CSV, they now receive only users within their own scope. The list totalCount and the users grid's approximate count now reflect that same scoped set.

Who is affected: Merchant users and reseller users are affected. Administrator results are unchanged.

What you need to do: If your integration used a merchant or reseller credential to list users outside that scope, use an administrator credential instead.

Breaking User lookup and changes now respect account scope

What changed: Identity user routes that target a user by ID, username, or email now only work for users within the caller's own merchant or reseller scope. If a merchant- or reseller-scoped user or API key targets a user outside that scope, the API now returns 404 Not Found for reads and leaves writes unchanged; GET /api/identity/users/{id}/access returns false, and POST /api/identity/users/{id}/restore returns false and restores nothing.

Who is affected: Merchants, resellers, and integrators using these identity user routes with merchant- or reseller-scoped credentials are affected if they read or change users outside their own scope. Callers whose roles have no ladder rung are also affected, because all of these routes are now refused for them.

What you need to do: If your integration works across merchants or resellers, use an administrator-scoped credential. If your roles have no ladder rung, give the role a role type or use an administrator credential.

Breaking Merchant credentials can no longer read other merchants' names

What changed: GET /api/merchants/{id}/name now returns an empty string when a merchant credential requests the name of a merchant it is not assigned to. The route, status code, and response format are unchanged.

Who is affected: This affects merchant credentials, including merchant users, MERCHANT (REPORT ONLY) users, and merchant API keys. Admin and reseller credentials are not affected.

What you need to do: If your integration uses a merchant credential, treat an empty name as "not found or not visible to this credential". If you need names for merchants that credential is not assigned to, use a reseller or administrator credential.

Breaking User creation and updates now enforce role and reseller checks

What changed: User create and update requests now reject invalid role, merchant, and reseller combinations before any user is written. Requests can now return 403 for unauthorized user type or merchant access, and 400 for an unknown resellerId, unknown RoleNames, or unknown OrganizationUnitIds.

Who is affected: Merchant users, API keys owned by merchant users, and callers using custom roles are affected when creating or updating users. This also affects callers who manage roles or organization units and send unknown values.

What you need to do: If you create reseller or administrator users, use reseller or administrator credentials. Update your integration to handle 403 and 400 responses for these cases, including ResellerId, RoleNames, and OrganizationUnitIds.

Breaking Wallet registration reads are now access-limited

What changed: For reseller and merchant users, and their API keys, wallet provider registration read endpoints now follow the same access rules as write endpoints. They now return only merchant-level registrations the caller is authorized to access; platform-level and other merchants' registrations are no longer available through the existing read routes, and some requests now return 403 or an empty string.

Who is affected: This affects non-administrator integrations that read platform-level wallet registrations or registrations belonging to other merchants. Administrators are not affected.

What you need to do: If your non-administrator integration needs to choose a platform registration to bind a merchant to, use GET /api/payment-tokenization/wallet-providers/platform/{providerType}/options. Also update your integration to handle the new behavior on existing read routes, including 403 responses and empty-string name responses.

Breaking Settlement run-state now requires MerchantId and RunId

What changed: The GET /api/transactions/settlements/run-state endpoint now requires both MerchantId and RunId query parameters. If either is missing, the endpoint returns 400 with a validation error that names the missing parameter.

Who is affected: This affects anyone calling the settlement run-state endpoint directly or through regenerated client libraries. It applies when your integration checks the status of a settlement run.

What you need to do: Always send both the merchant ID and the runId returned by the settlement trigger when calling GET /api/transactions/settlements/run-state.

Breaking Wallets no longer collect shipping addresses in locked sessions

What changed: In hosted-payment sessions with a locked shipping amount, Apple Pay, Google Pay, and Paze no longer ask the customer for a delivery address. The order uses the shipping address already on the page or one you prefilled, and the wallet's address screens no longer appear.

Who is affected: This affects merchants and integrators using hosted-payment sessions with a locked shipping amount and offering Apple Pay, Google Pay, or Paze. It also affects pages that require a shipping address before the wallet button opens.

What you need to do: If you want the wallet to supply the shipping address, do not lock the shipping amount on the session. If your page requires a shipping address, make sure the customer enters it on the page before opening the wallet, or prefill it.

Breaking API reference now shows the correct response content types

What changed: The published API reference now lists application/json for JSON responses, instead of text/plain or text/json. For file downloads, it now lists the actual file type, such as text/csv, the XLSX type, application/pdf, image/jpeg, or the CycloneDX type.

Who is affected: This affects anyone who generates a client from the API reference or manually sets the Accept header. Existing runtime behavior is unchanged, including status codes, headers, body content, and support for text/json negotiation.

What you need to do: If you generated a client from an earlier API document and it treats a JSON response as text/plain, regenerate it from /openapi/v1.json. If your client sets Accept itself, send application/json for JSON responses, or the file's actual type for a download.

UP Gateways changelog