Swipelux API changelog and release notes

​

Added

• Every entry from GET /v3/customers/{customerId}/capabilities/supported includes unavailableInstitutions. It lists the banks that offer the capability variant but do not accept this customer, each with an id, a name, and reasons in statusReason shape. Current reason codes are jurisdiction_unsupported, legal_form_unsupported, and customer_type_unsupported. The field is [] on pooled and non-bank entries, and a bank never appears in both institutions and unavailableInstitutions. Naming an unavailable bank in a capability request still returns 422 capability_institutions_unsupported. See Capabilities and requirements.

​

Added

• Authenticated requests are rate-limited per API key, per integrating business and per client IP address. A request over a limit returns 429 rate_limited with retryable: true and a Retry-After header that gives the seconds to wait before retrying. Integrating businesses that are not yet approved have lower limits. Every authenticated operation in the API reference lists the 429 response. Repeated failed authentications from one IP address also return 429 once over their limit, while valid API keys sent from that address keep working.

​

Added

• Webhook endpoints include disabled, which is true while deliveries to the endpoint are paused. Swipelux also pauses an endpoint after repeated delivery failures. Send disabled: true in PATCH /v3/webhooks/{webhookId} to pause deliveries and disabled: false to resume them. Resuming checks the destination URL again and returns 400 if it no longer passes, so the endpoint stays paused.

​

Changed

• POST /v3/customers/{customerId}/export with format: sumsub_share_token returns 422 kyc_provider_rejected with retryable: false when the identity verification provider refuses to create the share token, for example for an unknown forClientId, instead of 502 request_failed. The response carries a fixed Swipelux message and never repeats the provider’s error text, so check the request before retrying. Other provider failures still return 502 request_failed, which is retryable.
• The portal from GET /v3/webhooks/portal no longer creates, edits, pauses, or deletes endpoints. With an API key that has webhooks:write, it still shows and rotates the endpoint signing secret, retries deliveries, and replays them. Create endpoints with POST /v3/webhooks, change or pause them with PATCH /v3/webhooks/{webhookId}, and delete them with DELETE /v3/webhooks/{webhookId}. See Webhooks.

​

Changed

• Until your integrating business KYB is approved, you can make 20 webhook URL changes per hour in total, across all endpoints in your live spaces that require KYB. Changes in sandbox spaces do not count. Exceeding the webhook URL limit returns 422 merchant_kyb_not_approved. Changing only an endpoint’s events or saving its current URL does not count as a URL change. In the dashboard, Swipelux refuses more than 10 active API keys per live space that requires KYB with a plain 422 response. Swipelux also refuses more than 5 spaces per merchant with a plain 422 response while you have at least one live space, all your live spaces require KYB, and none is approved. The space limit counts sandbox and live spaces; it does not apply if any live space does not require KYB. Sandbox spaces are exempt from the write block, webhook URL limit, and key limit. See Go live.

​

Fixed

• POST /v3/quotes for a wallet move returns 404 not_found with Destination was not found. when the destination account belongs to another merchant. See Errors and retries.

​

Added

• Capabilities can report statusReason.code: offer_unavailable with status restricted and resolution: contact_support. Swipelux returns it when an approved application covers the capability but no current offer permits it. It replaces related_application_action_required with resolution: wait in this case, because waiting on the approved application changes nothing. Contact Swipelux support instead of waiting. See Capabilities and requirements.

​

Changed

• A sandbox key cannot move live funds. A quote that names a live account or destination returns 404 not_found, as an unknown ID does. For a wallet move to a live destination account, the response carries Destination was not found. See Key scope.

​

Added

• GET /v3/customers/{customerId}/transfer-totals returns a customer’s completed received and sent volume in USD. USD, USDC, and USDT count 1:1, and self transfers and other currencies are excluded. The endpoint needs customers:read. See Customers.

​

Changed

• In a live space that requires business KYB, every write request outside business verification and webhook management returns 422 merchant_kyb_not_approved until your integrating business KYB is approved. Before, only POST /v3/customers returned this error. Blocked requests include customer writes, capability, application, and account requests, recipients and destinations, rules, quotes, and transfers. GET and HEAD requests and your business verification (profile, related parties, documents, and task submissions for your business’s KYB customer) remain available. You can manage webhook endpoints through the API, and manage secret keys, spaces, and rail fees in the dashboard. Sandbox spaces and live spaces that do not require KYB are unchanged. See Go live and Errors and retries.

​

Added

• POST /v3/customers/{customerId}/tasks/{taskId}/verification-sessions/{verificationSessionId}/share-token imports an individual’s verification from your own account with Swipelux’s identity verification provider into the intake task’s identity_verification session. Send { "shareToken": "..." } with an Idempotency-Key. The session moves to in_review, or stays action_required when steps are missing. When the checks finish, Swipelux settles the covered requirements the same way as for a hosted session. The import covers the requirements listed in coveredRequirementIds: the ID document, selfie, and, where the task requires it, proof of address. Swipelux never stores or logs share tokens. The endpoint returns 409 verification_already_started when the customer already has a verification with Swipelux or an import is running, 422 share_token_rejected when the identity verification provider refuses the token, and 503 kyc_provider_unavailable, which is retryable only when the token was not yet sent. See Capabilities and requirements.
• Every verificationSessions[] entry in task reads and customer task detail includes coveredRequirementIds, the IDs of the live requirements the session can fill.

​

Changed

• New individual intake tasks no longer collect proof of funds in the hosted identity session. The proof_of_funds, source_of_funds_document, named_source_of_funds_document, and sole_proprietor_document requirements are ordinary document requirements. Upload the document, submit it with the task, and wait for Swipelux to review it. The hosted session covers only the ID document, selfie, and proof of address. Existing tasks and sessions keep working as before. See Capabilities and requirements.

​

Added

• Recipient destinations accept the pix and pix_safe types for BRL payouts in Brazil. A Pix destination pays a Pix key. A Pix Safe destination pays a bank account identified by the holder’s CPF or CNPJ, the bank’s ISPB code, the branch, and the account number. Both need the customer’s ready Pix capability (pix_pooled), and their payouts are funded with USDC and carry no developer fee. See Recipients and Send funds.
• GET /v3/customers/{customerId}/tasks/{taskId} accepts documentCandidatesFor with a document requirement ID, plus documentAlternativeKey for a requirement with alternatives. The response then lists, in data.documentCandidates, files the customer already uploaded that can answer that requirement, with any missingMetadata or conflictingMetadata. Submit a candidate’s documentId with the missing documentMetadata instead of uploading the file again. The query needs accounts:read and customers:read, and an invalid selection returns 400 validation_error.

​

Changed

• GET /v3/webhooks/portal returns a portal URL that expires after one hour, with Cache-Control: no-store. With an API key that has webhooks:write, the portal shows the endpoint signing secret and can manage endpoints, retry deliveries, and replay them. With only webhooks:read, the portal shows deliveries only. See Webhooks.
• Citi (citibank) is offered only to business customers. Every business keeps pooled Citi, and named Citi is offered only to businesses registered outside the US. When a customer is not offered Citi, the supported list omits it, naming it returns 422 capability_institutions_unsupported, and a method that only Citi offers is listed as disabled. A request without institutions selects among the remaining banks. Existing applications and accounts are unchanged.
• Named CFSB (cfsb) capabilities are offered only to US customers: businesses registered in the US and individuals who reside there. For other customers, the supported list omits named CFSB, and naming it returns 422 capability_institutions_unsupported. A request without institutions selects among the remaining banks. Pooled CFSB, customers whose country is unknown, and existing applications are unchanged.
• Lead Bank (lead_bank) named ACH, Wire, and SWIFT capabilities are offered only to customers that Lead Bank can onboard, based on their legal form and countries. For other customers, the supported list omits lead_bank, and naming it returns 422 capability_institutions_unsupported. Customers that Lead Bank already onboarded, and capabilities whose open request already names lead_bank, keep it. Existing applications and accounts are unchanged.
• RTP is pooled only. No bank offers rtp_named to new requests, so the supported list shows it as disabled. For a customer that does not hold rtp_named, a capability request or task preview for it that names a bank returns 422 capability_institutions_unsupported, and one without institutions returns 422 capability_variant_unavailable. Pooled RTP (rtp_pooled) is offered at Citi, so only business customers can request it.
• New identity document requests for individuals and beneficial owners can set constraints.identityMetadataRequired: true, so each file needs its ID number and issuing country in documentMetadata. New business proof-of-address and owner proof-of-residence requests can set constraints.maxIssueAgeDays: 90, so each file needs its issue date. Existing tasks keep their requirements, so read the constraints on each task request.
• A task answer to a business registration request, whose profilePointer is /business/registration, needs the jurisdiction country, the registration number, and a formation date before the submission date, all together. The request’s valueSchema publishes this rule, and a partial answer returns 400 validation_error.
• After a hosted verification, Swipelux accepts a hosted answer to a profile requirement for a structured value, such as an address or tax identifiers, only when it passes the same schema and constraint checks as a direct answer. Otherwise the requirement stays open, and you submit that value with POST /v3/customers/{customerId}/tasks/{taskId}/submissions. A requirement that Swipelux returns to action_required for this reason carries reviewFeedback.code: hosted_profile_direct_submission_required. Tasks that are already satisfied keep their status. See Capabilities and requirements.
• A task rejected by a hosted verification can leave rejected when that verification decision is later reversed. It then becomes satisfied, or action_required under a new revision with the requirements the new decision does not answer reopened. Earlier submissions for those requirements stay rejected, so submit those answers again. See Migrate to v3.
• Recipient destination type is now an open enum. Earlier versions of this reference described it as closed, so update any client that rejects or drops unknown types. Destination responses and destination.status_changed events can now carry pix and pix_safe, and more types can be added.
• Recipient create and update requests, including the nested address, ignore fields they do not define instead of returning 400 validation_error. In a create request, a name or industry field for the other recipient type still returns 400, and so do type and externalId in PATCH /v3/customers/{customerId}/recipients/{recipientId}. A PATCH with no field it recognizes returns 400 validation_error instead of 200.
• A verification link for an eligible session that only asks for documents now opens a Swipelux-hosted document upload page. The link itself is unchanged, and other sessions still open the hosted verification flow.
• employment.occupation on individual customers and related-party persons accepts at most 255 characters.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId}, and POST /v3/customers/{customerId}/tasks/{taskId}/submissions return 400 validation_error when a profile value or task answer contains a Swipelux form link, such as an RFI, customer request, or transfer tracking link. This does not apply to externalId or metadata. Each rejected value appears in errors[] with code: public_form_link and its JSON Pointer, and the response never repeats the link. Send the information itself instead. See Errors and retries.

​

Fixed

• Payout quote and transfer responses keep a USDC or USDT source amount to six decimal places, for example 4009.711365 instead of 4009.71. Fiat amounts keep two decimals. Creating or reading a payout whose stablecoin source amount has more than two decimals no longer returns 500.
• The POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel reference now describes cancellation as it works. You can cancel a ready capability, the stablecoin_transfers capability cannot be canceled, and canceling ends only that capability while its applications keep their status, tasks, and approvals.
• A capability request or task preview that lists a bank code in institutions instead of a public institution ID, such as citi for citibank, returns 422 capability_institutions_unsupported naming the available IDs instead of 503 kyc_configuration_unavailable.
• A capability request or task preview for a method that no bank offers to the customer, which the supported list shows as disabled, returns 422 capability_variant_unavailable with retryable: false instead of 503 kyc_configuration_unavailable, unless the customer already holds that capability.
• documentCandidates no longer lists files that Swipelux keeps from a completed hosted verification, which you cannot read or download. A task answer that cites one returns 400 invalid_document_reference, as an unknown document does.

​

Added

• GET /v3/customers accepts include=documentRequirements. Each customer summary then reports how many mandatory documents are still outstanding, independent of capability readiness. Combine it as include=capabilities,documentRequirements. See Customers.
• The merchant panel’s Webhooks page adds Replay missed events to the endpoint menu. It resends events from the last 13 days that the endpoint never received, and never sends the same event twice. See Webhooks.
• The merchant panel’s Settings page has a Compliance section. Owners and admins can set the compliance email and choose whether to receive emails when Swipelux requests more information about a customer.
• Merchants can answer their own KYB compliance requests inline on the merchant panel’s KYB page.

​

Changed

• Customer and related-party updates no longer return 409 field_conflicts_with_completed_intake after a bank intake is completed. The update saves, and each new bank application checks the latest profile against its own requirements.
• Capability requests return 409 capability_route_header_conflict when a capability’s existing bank routing cannot be updated safely. Contact Swipelux support before retrying.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview returns 422 capability_institutions_unsupported when institutions names a bank the capability does not offer, as capability requests already do.
• In the sandbox, ACH, Wire, and SWIFT capabilities are served at JPMorgan Chase only. Requests that omit institutions select jpmorgan, and naming another bank returns 422 capability_institutions_unsupported. Live routing is unchanged. See Test in the sandbox.
• Forcing a sandbox capability status returns 409 capability_status_blocked with a statusReason when the simulated case cannot reach the requested status. Repeating a force that already applied returns 200 unchanged. See Test in the sandbox.
• POST /v3/sandbox/tasks/{taskId}/review returns 409 task_not_sandbox_reviewable for a task that Operations or another workflow owns. Tasks from POST /v3/sandbox/tasks and the capability intake tasks that Swipelux collects remain reviewable. See Test in the sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} returns 409 account_provisioning_unresolved when you change settlement while the account is still being provisioned at the bank. Retry after provisioning settles. See Errors and retries.
• POST /v3/transfers can return 409 quote_execution_evidence_conflict. Create a new quote and execute it. See Errors and retries.
• The merchant panel’s Pay out drawer shows the full destination details, masks account numbers and wallet addresses behind a toggle, and shows an estimated arrival time for each payment method.
• The merchant panel folds bank accounts into the customer’s Payment access tab, with a tasks card that names each bank. The Documents tab moved into Profile.
• Opening a named bank account in the merchant panel is now a single step that lists each bank’s currency, methods, and onboarding time. See Accounts.
• Bank accounts held for review show as On hold in the merchant panel, with the account ID and a Contact support action.
• A pending capability now reports statusReason.code: preparing_submission instead of review_in_progress while Swipelux prepares an application for submission and no review is underway. Both codes use resolution: wait. A change between them keeps the status pending, so it sends no capability.status_changed event. Existing capabilities pick up the new code at their next reevaluation. See Capabilities and requirements.
• The Shared methods table on the customer’s Payment access tab in the merchant panel shows In preparation instead of In review for a pooled method whose capability reports preparing_submission.
• A capability’s applications list now shows only its current applications, in capability reads (including GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), capability request responses, and capability.status_changed events. An application that a newer one replaced still appears in GET /v3/customers/{customerId}/applications, where supersededByApplicationId names its successor. A replaced application’s open tasks still count in the capability’s openTaskIds. The capability’s status and openTaskIds do not change, so the change itself sends no webhook event. See Capabilities and requirements.

​

Fixed

• A second allowPending request for the same issued account, sent before the bank approves, returns 409 naming the waiting account in holder.accountId instead of 500. See Issue a bank account.
• Canceling a capability now closes issued account requests that were still waiting for bank approval, so a later request at the same bank starts fresh.
• Re-requesting a canceled capability whose bank cases were all rejected publishes a single capability.status_changed event from canceled.
• Re-requesting a bank after its earlier application was archived now submits the new application.
• Recipient destinations can be added as soon as the matching capability reads ready, instead of returning 409 rail_not_ready. See Recipients.
• Webhook events sent before you first open the merchant panel’s Webhooks page are now kept, so you can replay them to a new endpoint.
• Task due dates in the merchant panel show in your own timezone, and bank review drawers show All requirements submitted once nothing is left open.

​

Added

• POST /v3/quotes accepts an optional institutionId to pick an approved bank route for a crypto-to-fiat payout quote. Omit it to keep automatic routing. A bank that is not available for the payout returns 422 bank_not_supported_for_customer, and sending institutionId with any other quote type returns 400 validation_error. See Send funds.
• Issued bank account requests on POST /v3/customers/{customerId}/accounts accept institution to pin the account to one bank without fallback, and allowPending: true to save the request while that bank’s application is still awaiting approval. allowPending requires institution. Saved requests report the governing applicationId. See Issue a bank account.
• The merchant panel has a native Webhooks page for managing endpoints. See Webhooks.
• The merchant panel adds a Pay in drawer with named bank accounts, crypto deposits, and a review step.
• The merchant panel’s Pay out flow shows wallet balances in the source picker, adds a Max amount option, and includes a review step.
• Customer profiles in the merchant panel have a Recipients & destinations tab.
• Task requirements can include a short title heading. The request prompt still carries the guidance. See Capabilities and requirements.

​

Changed

• Wire pay-in quotes on pooled Wire routes now require at least $20. Quotes below a route’s minimum, or too small to cover transfer fees, return 422 amount_not_deliverable instead of a generic quote failure. See Receive funds.
• The webhook portal now groups v3 event types by resource and shows each event’s payload schema and an example. Legacy event types appear in a separate Legacy group and are marked deprecated. Endpoints that already subscribe to them keep receiving them; use v3 event types for new subscriptions. See Webhooks.
• Sandbox top-ups now emit transfer.created and transfer.state_changed webhook events. See Test in the sandbox.
• accountProvisioning now reports issued when the customer already has an active issued account. See Capabilities and requirements.
• Bank account details in the merchant panel open in a drawer with bank logos. See Accounts.
• The merchant panel labels money movement as Pay in and Pay out, keeps you signed in for six hours, and sends help requests to Swipelux support by email.
• In intake tasks that accept direct submission, eligible requirements already backed by the customer profile or uploaded documents move to in_review automatically. See Capabilities and requirements.

​

Fixed

• Re-requesting a canceled capability no longer fails because of superseded application records or outdated requirements.
• Capabilities stored under the retired Fedwire ID now read as wire instead of returning 500.

​

Added

• GET /v3/customers/{customerId}/applications lists a customer’s application cases, with the capabilities requested against each case and the capabilities its approval covers. One approval at a bank can cover several capabilities. Retained historical cases point to their successor through supersededByApplicationId. The list supports cursor pagination and updatedAfter. See Capabilities and requirements.
• POST /v3/customers/{customerId}/capabilities/{capabilityId} responses include selectedApplicationId for case-backed capabilities. It identifies the existing application case the request reused, or the case it opened. See Capabilities and requirements.
• Institutions returned by GET /v3/institutions and by the supported-capabilities list include a nullable logoUrl. Use it to show bank branding when available, and fall back to the institution name when it is null. See Capabilities and requirements.
• USD SWIFT payouts are now available. SWIFT payouts require at least 100 USD. The merchant panel collects SWIFT bank instructions for recipients. See Send funds.
• Issued bank accounts can receive over SWIFT with named receiving details. See Issue a bank account.
• USDT is now supported as a source for ACH and Wire payouts. See Send funds.
• Issued bank accounts accept settlement.currency of USDC or USDT to choose the stablecoin delivered to the settlement wallet, independent of the wallet account currency. Omit it to keep settling in the wallet’s currency. See Issue a bank account.
• SWIFT bank accounts and recipient destinations accept bankCity, bankState, bankPostalCode, and bankAddressLine2, plus optional beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode, and intermediary bank details. See Send funds.
• Issued bank account details include achRoutingNumber and wireRoutingNumber when the bank supplies separate ACH and Wire routing numbers, and bankLogoUrl for the receiving bank. See Issue a bank account.
• capability.created webhook events include applicationId and an origin of requested or approval, so you can tell capabilities you requested from ones an approval covered. See Webhooks.
• Requirement requests can declare a validation constraints.format, such as http_url, us_ssn, us_ein, or bank_industry_classification. See Capabilities and requirements.

​

Changed

• The merchant panel’s bank account creation now starts from bank selection, and bank accounts show separate ACH and Wire routing numbers. See Accounts.
• The network enum now includes solana. It is an open enum, so tolerate network values you do not recognize. See Accounts.
• Opening a hosted verification link for a task whose remaining requirements need direct submission returns 409 verification_session_not_allowed. Submit those requirements as a task submission instead. See Errors and retries.
• Archiving an issued account whose provisioning has not settled returns 409 account_provisioning_unresolved. Retry after provisioning settles. See Errors and retries.
• New named bank account requests are queued for provisioning as soon as the account is created, instead of waiting for the next customer refresh. See Issue a bank account.

​

Removed

• Pooled SWIFT receiving details are no longer offered for new accounts. Use named SWIFT receiving details instead. See Issue a bank account.

​

Fixed

• Payout transfer reads now return the quoted recipient.
• Creating an ACH account after archiving an existing one no longer returns 409, and archived pending account requests no longer hold an account slot.
• Bank fees on local-currency pay-in quotes are reported in the correct fiat currency.

​

Added

• GET /v3/webhooks/{webhookId} reads a single webhook endpoint and its events selection. See Webhooks.
• Task requirements now publish allowedValues and a JSON Schema valueSchema for profile fields, including required address fields. Country fields report a valueType or itemValueType of country, an ISO 3166-1 alpha-2 code. You can render inputs and choices without hardcoding them. See Capabilities and requirements.
• Existing Tron wallets can now send USDT to the customer’s external wallet accounts, and transfer reads include a block explorer link for Tron transactions. New wallets can’t be issued on Tron. See Send funds.
• Task requirements can declare requiredWhen (answer only when a named yes/no answer matches), profileAssertion (us_person), and ownershipPolicy, and document requests can set identityMetadataRequired and maxIssueAgeDays. Task answers accept documentMetadata (idNumber, issuingCountry, issuedOn) for referenced documents, and task reads return reviewed controlling answers in conditionValues. See Capabilities and requirements.
• Document requirements can list acceptedDocumentSets, and related-party requirements can ask for an associated_person or control_person qualification in addition to beneficial_owner. See Capabilities and requirements.
• Transfer correction objects now also cover failed funded payouts: kind: funding_failure with a recover_source_funding compensating action, a recoveryStatus of unknown or reported, and USDT credited outputs. See Quotes and transfers.

​

Changed

• PATCH /v3/webhooks/{webhookId} now accepts legacy event types that the endpoint already subscribes to, so you can keep them while you add v3 event types. events replaces the full selection, so include every event type you want to keep. Adding a legacy event type that the endpoint did not already have returns 400 validation_error. See Webhooks.
• Bank identifiers on recipients and accounts are validated before they are saved. See Recipients.
• Capability requests, task submissions, and sandbox status changes now return 409 capability_application_stale instead of 500 when a capability was created under an earlier onboarding model. See Errors and retries.
• The public RFI page is now one continuous form. It supports related people and collects one tax ID per person. See Document requirements.
• Quotes and transfers return 409 customer_bank_limit_exceeded when a payment exceeds the customer’s remaining daily or monthly allowance at the bank, and 503 customer_bank_limits_unavailable when that allowance cannot be checked. Transfers return 409 payout_execution_unavailable when a payout cannot start from its quote. See Errors and retries.
• Customer and related-party updates that conflict with a completed bank intake return 409 field_conflicts_with_completed_intake with the taskId and fields.

​

Fixed

• Canceled capability history remains readable.
• Wire payouts display and filter correctly in the merchant panel’s transaction list.

​

Changed

• POST /v3/transfers and transfer reads use checkoutMethod instead of paymentMethod for the card checkout pre-selection, and accept card, apple_pay, google_pay, cash_app, sepa, and blik. The list is open and can grow. paymentMethod is no longer recognized; requests that still send it are treated as if it were omitted. sepa and blik are funding options inside the card checkout, not Swipelux capabilities. See Receive funds.

​

Added

• POST /v3/transfers accepts an optional paymentMethod of card, apple_pay, or google_pay for card quotes. The hosted checkout opens on the requested method when it is available for the customer and their device, transfer reads echo the request, and the quote’s amounts and fees are unchanged. See Receive funds.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview accepts institutions to preview the tasks for specific banks returned by the supported-capabilities list. See Capabilities and requirements.

​

Changed

• Card quotes now reflect checkout fees and the net USDC delivered. See Receive funds.
• Rejected payout quotes return a specific problem code instead of a generic failure: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported, or quote_failed, and 503 quote_temporarily_unavailable when the quote can be retried later. See Errors and retries.

​

Fixed

• Card quotes no longer fail because of fee rounding.
• Reopening a hosted KYC link no longer returns 409 kyc_process_conflict when questionnaire answers include extra spaces.
• Stalled passkey withdrawal confirmations in the merchant panel now recover.

​

Added

• POST /v3/customers/{customerId}/documents now also accepts an application/json body with storageKey, fileName, and type. The storageKey must be a fresh customer-scoped reference parked through the earlier direct-upload flow, and the upload passes the same size and file-signature validation as multipart uploads. See Migrate to v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download returns a download url for an active customer document. The URL expires after one hour and serves the file as an attachment. Archived, unknown, and cross-customer documents return 404. See Capabilities and requirements.
• Requesting a capability for a business with no beneficial owner now creates an intake task to add one instead of failing with a 503. Requests that cannot proceed return 422 beneficial_owner_required with instructions to add an individual related party with declared or at least 25% ownership. See Shareholders, UBOs, and control persons.
• The merchant panel’s task table now shows each request’s subject and capability scope, so you can see who and what a compliance request covers. See Capabilities and requirements.
• Industry classification fields in the merchant panel now offer searchable NAICS codes on customer profiles and requirement tasks. See KYB workflow.
• Bank pay-in instructions can include bankName, bankAddress, accountHolderName, and accountHolderAddress. Show them with the other bank coordinates. See Receive funds.
• POST /v3/transfers accepts an optional redirectUrl that returns the customer to your app after a card or Apple Pay hosted checkout. Reaching the URL does not confirm completion; use transfer reads or webhooks. See Receive funds.
• Transfers created by a v3 Rule appear in transfer reads and lists with origin: rule and emit transfer.state_changed events like other transfers. Filter them with GET /v3/transfers?origin=rule. See Quotes and transfers.
• Identity documents on customers and related parties accept sideApplicability (front_only, front_and_back, or unknown), and tasks can collect identity-document details such as type, number, issuingCountry, issuingRegion, issuedOn, expiresOn, and doesNotExpire as answers. See Capabilities and requirements.

​

Changed

• Bank-detail submissions that conflict with an in-progress bank setup now return 409 ops_rail_handoff_conflict. Keep your uploaded document IDs and retry the same submission after the conflict is resolved instead of re-uploading documents. See Errors and retries.
• The minimum for unannounced stablecoin deposits into customer wallets is now 1 unit instead of 10. Smaller deposits are still treated as dust. See Receive funds.
• Webhook configuration is now isolated per environment. The webhook portal opens scoped to the environment you request it from, so sandbox and production endpoints no longer share settings. See Webhooks.
• The merchant panel now derives available pay-in methods from the customer’s v3 capabilities, so account setup only offers methods the customer is entitled to. See Accounts.
• RFI forms now collect qualifying beneficial owners with shorter, clearer prompts, and RFI history displays as lifecycle milestones. See Document requirements.
• Open tasks without an explicit due date now default dueAt to 31 days after creation. See Capabilities and requirements.

​

Removed

• The merchant panel no longer offers Fedwire when adding new pay-in methods. Existing Fedwire accounts remain readable. See Accounts.

​

Fixed

• Unannounced USDT deposits into customer wallets are now recognized and settled instead of being ignored.
• Evidence you have already submitted now carries over to other tasks that require the same item, so customers are not asked for the same document twice.
• Re-requesting a capability no longer discards bank routes that are already ready, so issued account details stay stable.
• Bank instruction views in the merchant panel now show complete details, including SWIFT addresses and the target wallet address.
• RFI forms now surface submission validation errors, validate legal form descriptions before submission, and accept multiple business websites.
• You can now edit related-person drafts in RFI forms before submitting.
• Canceled compliance requests no longer appear in the merchant panel task list.
• Document review statuses display correctly again in the merchant panel.

​

Added

• Customer-scoped hosted verification and Terms of Service sessions now include an authoritative action object. Follow its available or unavailable kind; the flat url and expiresAt fields remain compatibility mirrors for available actions. See Capabilities and requirements.
• Sandbox wallet top-ups now return transfer IDs that you can read with GET /v3/transfers/{transferId} or list with GET /v3/transfers. They appear as completed inbound stablecoin deposits. See Test in the sandbox.
• Transfer reads include a correction object when a transfer’s funds are returned or reversed after it completes. It reports the correction kind, the normalized providerStatus, any providerShortfall, and the compensatingIntent Swipelux applies. See Quotes and transfers.

​

Changed

• The merchant panel’s First pay-in walkthrough for card and Apple Pay now requires a Polygon wallet under the customer. Create that wallet before you start the walkthrough. See Accounts.
• New requests and public responses use sepa as the canonical method and capability name. The sepa_instant input alias and previously stored resources remain compatible, but public responses use sepa. See Accounts.
• New Faster Payments capability, issued-account, and quote requests are unavailable. Existing accounts, quotes, and transfers remain readable. See Accounts.
• The first KYB page no longer collects the representative’s birth date. Shareholder birth dates remain a separate requirement. See KYB workflow.
• RFI document references now accept the image/jpg MIME alias in addition to image/jpeg. See Document requirements.
• Task history in the merchant panel now presents a human-readable audit trail without revision counters. See Capabilities and requirements.
• Quotes and transfers now check the capability’s supported directions before any money moves. Using a capability in a direction it does not support returns 422 capability_direction_unsupported, and moves between wallets require a stablecoin_transfers capability. See Errors and retries.

​

Removed

• The merchant panel no longer offers new UAEFTS account setup. Existing UAEFTS accounts remain readable. See Accounts.

​

Fixed

• RFI forms preserve existing entries when a reviewer adds a new document drop, so previously supplied answers are no longer lost on resubmission.
• The merchant panel resumes hosted compliance sessions from available actions without discarding valid links.
• Hosted Terms of Service links now work for every task scope returned by the API.
• After you request Payment Access in the merchant panel, it opens the intake task returned by that request instead of a task from an earlier request.
• The merchant panel’s KYB demo now asks for the current required fields.
• A quote that reuses its source wallet as destinationId now returns actionable 422 quote_direction_invalid details before any provider work starts. See Quotes and transfers.
• The API rejects malformed query-string encoding with a 400 error instead of silently normalizing the request, so invalid inputs surface earlier. See Errors and retries.
• POST /v3/customers/{customerId}/documents now rejects empty, non-multipart, or malformed request bodies with a 400 error.

​

Added

• Published the v3 Problem Details catalog in the OpenAPI spec so integrators can map error responses directly from the schema. See Errors.
• Added customerId to v3 account webhook events, letting you correlate account activity to the owning customer without a follow-up read. See Webhooks.
• The merchant panel now exposes every v3 individual-profile field, so onboarding operators can review and edit all KYC data collected through the API. See Onboard customers.
• Published a developer migration guide for v3. See Migrate to v3.

​

Changed

• Customer and account country codes are now validated as assigned ISO 3166-1 alpha-2 values at write time. Reads tolerate legacy stored values so existing records keep resolving. See Accounts.
• USDC availability is now scoped by destination network, so quotes and transfers offer USDC only on networks that the destination supports.
• Every onboarding flow now requires the Swipelux Terms of Service. Existing sessions remain resumable. See Onboard customers.
• Capability.ready continues to report entitlement approval. Use accountProvisioning to track account issuance as not_applicable, not_started, in_progress, issued, or failed. See Capabilities and requirements.
• HEIC uploads from iPhone are now accepted as identity and address documents.
• Clearing a customer or related-party field that an open task still requires now returns 409 field_required_by_open_task with the blocking taskId and fields, instead of a retryable conflict. Complete or cancel the task before you change those fields. See Errors and retries.

​

Fixed

• Re-executing a consumed quote now returns 409 quote_execution_consumed instead of a generic error. See Quotes and transfers.
• Transfer list and quote amount reads no longer return 500 for large historical result sets.
• Concurrent KYC redirects now return a conflict instead of 404, so retries resolve cleanly. Hosted redirects no longer roll back midway, and KYC links remain resumable.
• Related-party reads for individual customers no longer return 404.
• KYB submissions with invalid wallet fields are rejected before submission, and failed synchronization is no longer reported as success in the merchant panel.
• Requirement tasks in the merchant panel now show submitted responses as complete, track terms actions separately, remove duplicate document text, keep started KYC sessions pending until completion, and handle stale tasks without breaking the requirements view.
• Verification-link rows in the merchant panel now show an Open action on every row, and every task link renders in the requirements view.