Swipelux API changelog en release-opmerkingen

​

Toegevoegd

• Ontvangerbestemmingen accepteren de typen pix en pix_safe voor BRL-uitbetalingen in Brazilië. Een Pix-bestemming betaalt uit aan een Pix-sleutel. Een Pix Safe-bestemming betaalt uit aan een bankrekening die wordt geïdentificeerd door de CPF of CNPJ van de houder, de ISPB-code van de bank, het filiaal en het rekeningnummer. Beide vereisen de gereedstaande Pix-mogelijkheid van de klant (pix_pooled), en hun uitbetalingen worden gefinancierd met USDC en hebben geen ontwikkelaarsvergoeding. Zie Ontvangers en Geld versturen.
• GET /v3/customers/{customerId}/tasks/{taskId} accepteert documentCandidatesFor met een documentvereiste-ID, plus documentAlternativeKey voor een vereiste met alternatieven. Het antwoord toont dan in data.documentCandidates bestanden die de klant al heeft geüpload en die aan die vereiste kunnen voldoen, met eventuele missingMetadata of conflictingMetadata. Dien de documentId van een kandidaat in met de ontbrekende documentMetadata in plaats van het bestand opnieuw te uploaden. De query vereist accounts:read en customers:read, en een ongeldige selectie retourneert 400 validation_error.

​

Gewijzigd

• GET /v3/webhooks/portal retourneert een portal-URL die na één uur verloopt, met Cache-Control: no-store. Met een API-sleutel die webhooks:write heeft, toont de portal het ondertekeningsgeheim van het endpoint en kan deze endpoints beheren, leveringen opnieuw proberen en ze opnieuw afspelen. Met alleen webhooks:read toont de portal alleen leveringen. Zie Webhooks.
• Citi (citibank) wordt alleen aangeboden aan zakelijke klanten. Elk bedrijf behoudt gedeelde (pooled) Citi, en benoemde Citi wordt alleen aangeboden aan bedrijven die buiten de VS zijn geregistreerd. Wanneer Citi niet aan een klant wordt aangeboden, laat de lijst met ondersteunde mogelijkheden het weg, retourneert het noemen ervan 422 capability_institutions_unsupported, en wordt een methode die alleen Citi aanbiedt vermeld als disabled. Een aanvraag zonder institutions kiest uit de overige banken. Bestaande aanvragen en rekeningen blijven ongewijzigd.
• Benoemde CFSB-mogelijkheden (cfsb) worden alleen aangeboden aan Amerikaanse klanten: bedrijven die in de VS zijn geregistreerd en particulieren die daar wonen. Voor andere klanten laat de lijst met ondersteunde mogelijkheden benoemde CFSB weg, en retourneert het noemen ervan 422 capability_institutions_unsupported. Een aanvraag zonder institutions kiest uit de overige banken. Gedeelde (pooled) CFSB, klanten van wie het land onbekend is en bestaande aanvragen blijven ongewijzigd.
• Benoemde ACH-, Wire- en SWIFT-mogelijkheden van Lead Bank (lead_bank) worden alleen aangeboden aan klanten die Lead Bank kan onboarden, op basis van hun rechtsvorm en landen. Voor andere klanten laat de lijst met ondersteunde mogelijkheden lead_bank weg, en retourneert het noemen ervan 422 capability_institutions_unsupported. Klanten die Lead Bank al heeft geonboard, en mogelijkheden waarvan de openstaande aanvraag al lead_bank noemt, behouden het. Bestaande aanvragen en rekeningen blijven ongewijzigd.
• RTP is alleen gedeeld (pooled) beschikbaar. Geen enkele bank biedt rtp_named aan voor nieuwe aanvragen, dus de lijst met ondersteunde mogelijkheden vermeldt het als disabled. Voor een klant die rtp_named niet heeft, retourneert een aanvraag of takenvoorbeeld voor deze mogelijkheid dat een bank noemt 422 capability_institutions_unsupported, en een zonder institutions retourneert 422 capability_variant_unavailable. Gedeelde (pooled) RTP (rtp_pooled) wordt aangeboden bij Citi, dus alleen zakelijke klanten kunnen het aanvragen.
• Nieuwe verzoeken om identiteitsdocumenten voor particulieren en uiteindelijk belanghebbenden kunnen constraints.identityMetadataRequired: true instellen, zodat elk bestand het ID-nummer en het land van uitgifte in documentMetadata nodig heeft. Nieuwe verzoeken om een adresbewijs van een bedrijf en een verblijfsbewijs van een eigenaar kunnen constraints.maxIssueAgeDays: 90 instellen, zodat elk bestand de uitgiftedatum nodig heeft. Bestaande taken behouden hun vereisten, dus lees de beperkingen bij elk taakverzoek.
• Een taakantwoord op een verzoek om bedrijfsregistratie, waarvan de profilePointer /business/registration is, heeft het land van de jurisdictie, het registratienummer en een oprichtingsdatum vóór de indieningsdatum nodig, allemaal samen. Het valueSchema van het verzoek publiceert deze regel, en een gedeeltelijk antwoord retourneert 400 validation_error.
• Na een gehoste verificatie accepteert Swipelux een gehost antwoord op een profielvereiste voor een gestructureerde waarde, zoals een adres of fiscale identificatienummers, alleen als het dezelfde schema- en constraintcontroles doorstaat als een direct antwoord. Anders blijft de vereiste open en dien je die waarde in met POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Een vereiste die Swipelux om deze reden terugzet naar action_required, bevat reviewFeedback.code: hosted_profile_direct_submission_required. Taken die al satisfied zijn, behouden hun status. Zie Mogelijkheden en vereisten.
• Een taak die door een gehoste verificatie is afgewezen, kan rejected verlaten wanneer die verificatiebeslissing later wordt teruggedraaid. De taak wordt dan satisfied, of action_required onder een nieuwe revision, waarbij de vereisten die de nieuwe beslissing niet beantwoordt opnieuw worden geopend. Eerdere indieningen voor die vereisten blijven rejected, dus dien die antwoorden opnieuw in. Zie Migreren naar v3.
• Het type van een ontvangerbestemming is nu een open enum. Eerdere versies van deze referentie beschreven het als gesloten, dus werk elke client bij die onbekende typen weigert of laat vallen. Bestemmingsantwoorden en destination.status_changed-events kunnen nu pix en pix_safe bevatten, en er kunnen meer typen worden toegevoegd.
• Verzoeken om ontvangers aan te maken en bij te werken, inclusief het geneste address, negeren velden die ze niet definiëren in plaats van 400 validation_error te retourneren. In een aanmaakverzoek retourneert een naam- of sectorveld voor het andere ontvangertype nog steeds 400, net als type en externalId in PATCH /v3/customers/{customerId}/recipients/{recipientId}. Een PATCH zonder veld dat deze herkent, retourneert 400 validation_error in plaats van 200.
• Een verificatielink voor een geschikte sessie die alleen om documenten vraagt, opent nu een door Swipelux gehoste pagina voor het uploaden van documenten. De link zelf is ongewijzigd, en andere sessies openen nog steeds de gehoste verificatieflow.
• employment.occupation bij particuliere klanten en personen van gerelateerde partijen accepteert maximaal 255 tekens.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} en POST /v3/customers/{customerId}/tasks/{taskId}/submissions retourneren 400 validation_error wanneer een profielwaarde of taakantwoord een Swipelux-formulierlink bevat, zoals een RFI-, klantverzoek- of transfertrackinglink. Dit geldt niet voor externalId of metadata. Elke afgewezen waarde verschijnt in errors[] met code: public_form_link en de bijbehorende JSON Pointer, en het antwoord herhaalt de link nooit. Stuur in plaats daarvan de informatie zelf. Zie Fouten en nieuwe pogingen.

​

Opgelost

• Antwoorden van uitbetalingsquotes en transfers behouden een USDC- of USDT-bronbedrag met zes decimalen, bijvoorbeeld 4009.711365 in plaats van 4009.71. Fiatbedragen behouden twee decimalen. Het aanmaken of lezen van een uitbetaling waarvan het stablecoin-bronbedrag meer dan twee decimalen heeft, retourneert niet langer 500.
• De referentie van POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel beschrijft annulering nu zoals die werkt. Je kunt een ready mogelijkheid annuleren, de mogelijkheid stablecoin_transfers kan niet worden geannuleerd, en annuleren beëindigt alleen die mogelijkheid terwijl de aanvragen ervan hun status, taken en goedkeuringen behouden.
• Een aanvraag of takenvoorbeeld voor een mogelijkheid met in institutions een bankcode in plaats van een openbare instelling-ID, zoals citi voor citibank, retourneert 422 capability_institutions_unsupported met de beschikbare ID’s in plaats van 503 kyc_configuration_unavailable.
• Een aanvraag of takenvoorbeeld voor een methode die geen enkele bank aan de klant aanbiedt, en die de lijst met ondersteunde mogelijkheden als disabled vermeldt, retourneert 422 capability_variant_unavailable met retryable: false in plaats van 503 kyc_configuration_unavailable, tenzij de klant die mogelijkheid al heeft.
• documentCandidates toont niet langer bestanden die Swipelux bewaart van een voltooide gehoste verificatie, die je niet kunt lezen of downloaden. Een taakantwoord dat zo’n bestand vermeldt, retourneert 400 invalid_document_reference, net als een onbekend document.

​

Toegevoegd

• GET /v3/customers accepteert include=documentRequirements. Elke klantsamenvatting meldt dan hoeveel verplichte documenten nog openstaan, onafhankelijk van de gereedheid van mogelijkheden. Combineer het als include=capabilities,documentRequirements. Zie Klanten.
• De Webhooks-pagina van het merchantpanel voegt Replay missed events toe aan het endpointmenu. Hiermee worden events uit de afgelopen 13 dagen die het endpoint nooit heeft ontvangen opnieuw verstuurd, en wordt hetzelfde event nooit twee keer verstuurd. Zie Webhooks.
• De pagina Settings van het merchantpanel heeft een sectie Compliance. Eigenaren en beheerders kunnen het compliance-e-mailadres instellen en kiezen of ze e-mails ontvangen wanneer Swipelux om meer informatie over een klant vraagt.
• Merchants kunnen hun eigen KYB-complianceverzoeken direct beantwoorden op de KYB-pagina van het merchantpanel.

​

Gewijzigd

• Updates van klanten en gerelateerde partijen retourneren na een voltooide bankinname niet langer 409 field_conflicts_with_completed_intake. De update wordt opgeslagen en elke nieuwe bankaanvraag controleert het meest recente profiel aan de hand van de eigen vereisten.
• Aanvragen van mogelijkheden retourneren 409 capability_route_header_conflict wanneer de bestaande bankroutering van een mogelijkheid niet veilig kan worden bijgewerkt. Neem contact op met Swipelux-support voordat je het opnieuw probeert.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview retourneert 422 capability_institutions_unsupported wanneer institutions een bank noemt die de mogelijkheid niet aanbiedt, net als aanvragen van mogelijkheden.
• In de sandbox worden ACH-, Wire- en SWIFT-mogelijkheden alleen bij JPMorgan Chase aangeboden. Aanvragen zonder institutions selecteren jpmorgan, en het noemen van een andere bank retourneert 422 capability_institutions_unsupported. De live routering is ongewijzigd. Zie Testen in de sandbox.
• Het forceren van de status van een sandbox-mogelijkheid retourneert 409 capability_status_blocked met een statusReason wanneer het gesimuleerde geval de gevraagde status niet kan bereiken. Het herhalen van een geforceerde status die al is toegepast, retourneert 200 zonder wijzigingen. Zie Testen in de sandbox.
• POST /v3/sandbox/tasks/{taskId}/review retourneert 409 task_not_sandbox_reviewable voor een taak die eigendom is van Operations of een andere workflow. Taken van POST /v3/sandbox/tasks en de capability-intaketaken die Swipelux verzamelt, blijven reviewbaar. Zie Testen in de sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} retourneert 409 account_provisioning_unresolved wanneer je de settlement wijzigt terwijl de rekening nog bij de bank wordt geprovisioned. Probeer het opnieuw nadat de provisioning is afgerond. Zie Fouten en nieuwe pogingen.
• POST /v3/transfers kan 409 quote_execution_evidence_conflict retourneren. Maak een nieuwe quote aan en voer die uit. Zie Fouten en nieuwe pogingen.
• De Pay out-lade van het merchantpanel toont de volledige bestemmingsgegevens, verbergt rekeningnummers en walletadressen achter een schakelaar en toont een geschatte aankomsttijd voor elke betaalmethode.
• Het merchantpanel brengt bankrekeningen onder in het tabblad Payment access van de klant, met een takenkaart die elke bank noemt. Het tabblad Documents is verplaatst naar Profile.
• Het openen van een benoemde bankrekening in het merchantpanel is nu één stap die per bank de valuta, methoden en onboardingtijd toont. Zie Rekeningen.
• Bankrekeningen die voor controle zijn aangehouden, worden in het merchantpanel weergegeven als On hold, met de rekening-ID en een actie Contact support.
• Een pending capability meldt nu statusReason.code: preparing_submission in plaats van review_in_progress terwijl Swipelux een aanvraag voorbereidt voor indiening en er geen beoordeling loopt. Beide codes gebruiken resolution: wait. Een wisseling tussen beide houdt de status op pending, dus er wordt geen capability.status_changed-event verzonden. Bestaande capabilities krijgen de nieuwe code bij hun volgende herbeoordeling. Zie Mogelijkheden en vereisten.
• De tabel Shared methods op het tabblad Payment access van de klant in het merchantpanel toont In preparation in plaats van In review voor een gedeelde methode waarvan de capability preparing_submission meldt.
• De applications-lijst van een capability toont nu alleen de huidige aanvragen, in capability-reads (inclusief GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), responses op capability-aanvragen en capability.status_changed-events. Een aanvraag die door een nieuwere is vervangen, verschijnt nog steeds in GET /v3/customers/{customerId}/applications, waar supersededByApplicationId de opvolger noemt. Open taken van een vervangen aanvraag tellen nog steeds mee in de openTaskIds van de capability. De status en openTaskIds van de capability veranderen niet, dus de wijziging zelf verstuurt geen webhook-event. Zie Mogelijkheden en vereisten.

​

Opgelost

• Een tweede allowPending-verzoek voor dezelfde uitgegeven rekening, verstuurd voordat de bank goedkeurt, retourneert 409 met de wachtende rekening in holder.accountId in plaats van 500. Zie Een bankrekening uitgeven.
• Het annuleren van een mogelijkheid sluit nu verzoeken voor uitgegeven rekeningen die nog op goedkeuring van de bank wachtten, zodat een later verzoek bij dezelfde bank opnieuw begint.
• Het opnieuw aanvragen van een geannuleerde mogelijkheid waarvan alle bankdossiers zijn afgewezen, publiceert één capability.status_changed-event vanaf canceled.
• Het opnieuw aanvragen van een bank nadat de eerdere aanvraag is gearchiveerd, dient nu de nieuwe aanvraag in.
• Ontvangerbestemmingen kunnen worden toegevoegd zodra de bijbehorende mogelijkheid ready is, in plaats van 409 rail_not_ready te retourneren. Zie Ontvangers.
• Webhook-events die zijn verstuurd voordat je de Webhooks-pagina van het merchantpanel voor het eerst opende, worden nu bewaard, zodat je ze opnieuw naar een nieuw endpoint kunt versturen.
• Vervaldatums van taken in het merchantpanel worden in je eigen tijdzone weergegeven, en bankcontrolelades tonen All requirements submitted zodra er niets meer openstaat.

​

Toegevoegd

• POST /v3/quotes accepteert een optionele institutionId om een goedgekeurde bankroute te kiezen voor een quote voor een crypto-naar-fiat-uitbetaling. Laat dit weg om automatische routering te behouden. Een bank die niet beschikbaar is voor de uitbetaling, retourneert 422 bank_not_supported_for_customer, en het versturen van institutionId bij elk ander quotetype retourneert 400 validation_error. Zie Geld versturen.
• Verzoeken voor uitgegeven bankrekeningen op POST /v3/customers/{customerId}/accounts accepteren institution om de rekening zonder terugval aan één bank te koppelen, en allowPending: true om het verzoek op te slaan terwijl de aanvraag bij die bank nog op goedkeuring wacht. allowPending vereist institution. Opgeslagen verzoeken vermelden de bepalende applicationId. Zie Een bankrekening uitgeven.
• Het merchantpanel heeft een native Webhooks-pagina voor het beheren van endpoints. Zie Webhooks.
• Het merchantpanel voegt een Pay in-lade toe met benoemde bankrekeningen, cryptostortingen en een controlestap.
• De Pay out-flow van het merchantpanel toont walletsaldi in de bronkiezer, voegt een bedragoptie Max toe en bevat een controlestap.
• Klantprofielen in het merchantpanel hebben een tabblad Recipients & destinations.
• Taakvereisten kunnen een korte kop title bevatten. De prompt van het verzoek bevat nog steeds de toelichting. Zie Mogelijkheden en vereisten.

​

Gewijzigd

• Quotes voor wire-pay-ins op gedeelde (pooled) Wire-routes vereisen nu minimaal $20. Quotes onder het minimum van een route, of die te klein zijn om de overboekingskosten te dekken, retourneren 422 amount_not_deliverable in plaats van een algemene quotefout. Zie Geld ontvangen.
• Het webhookportaal groepeert v3-eventtypen nu per resource en toont voor elk event het payloadschema en een voorbeeld. Legacy-eventtypen verschijnen in een aparte groep Legacy en zijn gemarkeerd als verouderd. Endpoints die er al op zijn geabonneerd, blijven ze ontvangen; gebruik v3-eventtypen voor nieuwe abonnementen. Zie Webhooks.
• Sandbox-top-ups versturen nu de webhookgebeurtenissen transfer.created en transfer.state_changed. Zie Testen in de sandbox.
• accountProvisioning meldt nu issued wanneer de klant al een actieve uitgegeven rekening heeft. Zie Mogelijkheden en vereisten.
• Bankrekeninggegevens in het merchantpanel openen in een lade met banklogo’s. Zie Rekeningen.
• Het merchantpanel labelt geldbewegingen als Pay in en Pay out, houdt je zes uur ingelogd en stuurt hulpverzoeken per e-mail naar Swipelux-support.
• In innametaken die directe indiening accepteren, gaan in aanmerking komende vereisten die al worden onderbouwd door het klantprofiel of geüploade documenten automatisch naar in_review. Zie Mogelijkheden en vereisten.

​

Opgelost

• Het opnieuw aanvragen van een geannuleerde mogelijkheid mislukt niet langer door vervangen aanvraagrecords of verouderde vereisten.
• Mogelijkheden die zijn opgeslagen onder de buiten gebruik gestelde Fedwire-ID worden nu gelezen als wire in plaats van 500 te retourneren.

​

Toegevoegd

• GET /v3/customers/{customerId}/applications geeft de aanvraagdossiers van een klant weer, met de mogelijkheden die voor elk dossier zijn aangevraagd en de mogelijkheden die de goedkeuring ervan dekt. Eén goedkeuring bij een bank kan meerdere mogelijkheden dekken. Bewaarde historische dossiers verwijzen via supersededByApplicationId naar hun opvolger. De lijst ondersteunt cursorpaginering en updatedAfter. Zie Mogelijkheden en vereisten.
• Antwoorden van POST /v3/customers/{customerId}/capabilities/{capabilityId} bevatten selectedApplicationId voor mogelijkheden die op een dossier zijn gebaseerd. Het identificeert het bestaande aanvraagdossier dat het verzoek hergebruikte, of het dossier dat het opende. Zie Mogelijkheden en vereisten.
• Instellingen die worden geretourneerd door GET /v3/institutions en door de lijst met ondersteunde mogelijkheden, bevatten een nullable logoUrl. Gebruik deze om de huisstijl van de bank te tonen wanneer beschikbaar, en val terug op de naam van de instelling wanneer deze null is. Zie Mogelijkheden en vereisten.
• USD SWIFT-uitbetalingen zijn nu beschikbaar. SWIFT-uitbetalingen vereisen minimaal 100 USD. Het merchantpanel verzamelt SWIFT-bankinstructies voor ontvangers. Zie Geld versturen.
• Uitgegeven bankrekeningen kunnen via SWIFT ontvangen met benoemde ontvangstgegevens. Zie Een bankrekening uitgeven.
• USDT wordt nu ondersteund als bron voor ACH- en Wire-uitbetalingen. Zie Geld versturen.
• Uitgegeven bankrekeningen accepteren settlement.currency met USDC of USDT om de stablecoin te kiezen die in de settlement-wallet wordt geleverd, onafhankelijk van de valuta van de walletrekening. Laat het weg om te blijven afrekenen in de valuta van de wallet. Zie Een bankrekening uitgeven.
• SWIFT-bankrekeningen en ontvangerbestemmingen accepteren bankCity, bankState, bankPostalCode en bankAddressLine2, plus optioneel beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode en gegevens van een intermediaire bank. Zie Geld versturen.
• Gegevens van uitgegeven bankrekeningen bevatten achRoutingNumber en wireRoutingNumber wanneer de bank aparte ACH- en Wire-routingnummers levert, en bankLogoUrl voor de ontvangende bank. Zie Een bankrekening uitgeven.
• Webhookgebeurtenissen capability.created bevatten applicationId en een origin met de waarde requested of approval, zodat je mogelijkheden die je hebt aangevraagd kunt onderscheiden van mogelijkheden die door een goedkeuring worden gedekt. Zie Webhooks.
• Vereisteverzoeken kunnen een validatieformaat constraints.format opgeven, zoals http_url, us_ssn, us_ein of bank_industry_classification. Zie Mogelijkheden en vereisten.

​

Gewijzigd

• Het aanmaken van een bankrekening in het merchantpanel begint nu met de bankselectie, en bankrekeningen tonen aparte ACH- en Wire-routingnummers. Zie Rekeningen.
• De enum network bevat nu solana. Het is een open enum, dus houd rekening met netwerkwaarden die je niet herkent. Zie Rekeningen.
• Het openen van een gehoste verificatielink voor een taak waarvan de resterende vereisten directe indiening vereisen, retourneert 409 verification_session_not_allowed. Dien die vereisten in plaats daarvan in als taakindiening. Zie Fouten en nieuwe pogingen.
• Het archiveren van een uitgegeven rekening waarvan de provisioning nog niet is afgerond, retourneert 409 account_provisioning_unresolved. Probeer het opnieuw nadat de provisioning is afgerond. Zie Fouten en nieuwe pogingen.
• Nieuwe verzoeken voor benoemde bankrekeningen worden in de wachtrij voor provisioning geplaatst zodra de rekening is aangemaakt, in plaats van te wachten op de volgende vernieuwing van de klant. Zie Een bankrekening uitgeven.

​

Verwijderd

• Gedeelde (pooled) SWIFT-ontvangstgegevens worden niet langer aangeboden voor nieuwe rekeningen. Gebruik in plaats daarvan benoemde SWIFT-ontvangstgegevens. Zie Een bankrekening uitgeven.

​

Opgelost

• Het lezen van uitbetalingsoverboekingen retourneert nu de ontvanger uit de quote.
• Het aanmaken van een ACH-rekening na het archiveren van een bestaande retourneert niet langer 409, en gearchiveerde openstaande rekeningverzoeken bezetten niet langer een rekeningplaats.
• Bankkosten op pay-in-quotes in lokale valuta worden in de juiste fiatvaluta gerapporteerd.

​

Toegevoegd

• GET /v3/webhooks/{webhookId} leest één webhook-endpoint en de bijbehorende events-selectie. Zie Webhooks.
• Taakvereisten publiceren nu allowedValues en een JSON Schema-valueSchema voor profielvelden, inclusief verplichte adresvelden. Landvelden rapporteren valueType of itemValueType met de waarde country, wat een ISO 3166-1 alpha-2-code betekent. Je kunt invoervelden en keuzes weergeven zonder ze te hardcoderen. Zie Mogelijkheden en vereisten.
• Bestaande Tron-wallets kunnen nu USDT versturen naar de externe walletrekeningen van de klant, en transfer-reads bevatten een blockexplorer-link voor Tron-transacties. Nieuwe wallets kunnen niet op Tron worden uitgegeven. Zie Geld versturen.
• Taakvereisten kunnen requiredWhen (alleen beantwoorden wanneer een benoemd ja/nee-antwoord overeenkomt), profileAssertion (us_person) en ownershipPolicy opgeven, en documentverzoeken kunnen identityMetadataRequired en maxIssueAgeDays instellen. Taakantwoorden accepteren documentMetadata (idNumber, issuingCountry, issuedOn) voor gerefereerde documenten, en taak-reads retourneren beoordeelde bepalende antwoorden in conditionValues. Zie Mogelijkheden en vereisten.
• Documentvereisten kunnen acceptedDocumentSets vermelden, en vereisten voor gerelateerde partijen kunnen naast beneficial_owner ook om een kwalificatie als associated_person of control_person vragen. Zie Mogelijkheden en vereisten.
• correction-objecten van transfers dekken nu ook mislukte gefinancierde uitbetalingen: kind: funding_failure met een compenserende actie recover_source_funding, een recoveryStatus van unknown of reported, en gecrediteerde outputs in USDT. Zie Quotes en transfers.

​

Gewijzigd

• PATCH /v3/webhooks/{webhookId} accepteert nu legacy-eventtypen waarop het endpoint al is geabonneerd, zodat je ze kunt behouden terwijl je v3-eventtypen toevoegt. events vervangt de volledige selectie, dus neem elk eventtype op dat je wilt behouden. Het toevoegen van een legacy-eventtype dat het endpoint nog niet had, retourneert 400 validation_error. Zie Webhooks.
• Bank-ID’s op ontvangers en rekeningen worden gevalideerd voordat ze worden opgeslagen. Zie Ontvangers.
• Aanvragen van mogelijkheden, taakindieningen en statuswijzigingen in de sandbox retourneren nu 409 capability_application_stale in plaats van 500 wanneer een mogelijkheid is aangemaakt onder een eerder onboardingmodel. Zie Fouten en nieuwe pogingen.
• De openbare RFI-pagina is nu één doorlopend formulier. Het ondersteunt gerelateerde personen en verzamelt één fiscaal nummer per persoon. Zie Documentvereisten.
• Quotes en transfers retourneren 409 customer_bank_limit_exceeded wanneer een betaling de resterende dag- of maandlimiet van de klant bij de bank overschrijdt, en 503 customer_bank_limits_unavailable wanneer die limiet niet kan worden gecontroleerd. Transfers retourneren 409 payout_execution_unavailable wanneer een uitbetaling niet vanuit de quote kan starten. Zie Fouten en nieuwe pogingen.
• Updates van klanten en gerelateerde partijen die conflicteren met een voltooide bankinname retourneren 409 field_conflicts_with_completed_intake met de taskId en fields.

​

Opgelost

• De geschiedenis van geannuleerde mogelijkheden blijft leesbaar.
• Wire-uitbetalingen worden correct weergegeven en gefilterd in de transactielijst van het merchantpanel.

​

Gewijzigd

• POST /v3/transfers en transfer-reads gebruiken checkoutMethod in plaats van paymentMethod voor de voorselectie in de kaart-checkout, en accepteren card, apple_pay, google_pay, cash_app, sepa en blik. De lijst is open en kan groeien. paymentMethod wordt niet meer herkend; verzoeken die het nog steeds versturen, worden behandeld alsof het was weggelaten. sepa en blik zijn betaalopties binnen de kaart-checkout, geen Swipelux-capabilities. Zie Geld ontvangen.

​

Toegevoegd

• POST /v3/transfers accepteert voor kaart-quotes een optionele paymentMethod met de waarde card, apple_pay of google_pay. De gehoste checkout opent met de aangevraagde methode wanneer die beschikbaar is voor de klant en zijn apparaat, transfer-reads geven het verzoek terug, en de bedragen en kosten van de quote blijven ongewijzigd. Zie Geld ontvangen.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview accepteert institutions om een voorbeeld te tonen van de taken voor specifieke banken die door de lijst met ondersteunde mogelijkheden worden geretourneerd. Zie Mogelijkheden en vereisten.

​

Gewijzigd

• Kaartquotes weerspiegelen nu checkoutkosten en de netto geleverde USDC. Zie Geld ontvangen.
• Afgewezen uitbetalingsquotes retourneren een specifieke probleemcode in plaats van een algemene fout: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported of quote_failed, en 503 quote_temporarily_unavailable wanneer de quote later opnieuw kan worden geprobeerd. Zie Fouten en nieuwe pogingen.

​

Opgelost

• Kaartquotes mislukken niet langer door afronding van kosten.
• Het opnieuw openen van een gehoste KYC-link retourneert niet langer 409 kyc_process_conflict wanneer antwoorden op de vragenlijst extra spaties bevatten.
• Vastgelopen passkey-bevestigingen voor opnames in het merchantpanel herstellen nu.

​

Toegevoegd

• POST /v3/customers/{customerId}/documents accepteert nu ook een application/json-body met storageKey, fileName en type. De storageKey moet een verse, klant-gescopete referentie zijn die via de eerdere direct-upload-flow is geparkeerd, en de upload doorloopt dezelfde validatie van grootte en bestandshandtekening als multipart-uploads. Zie Migreren naar v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download retourneert een download-url voor een actief klantdocument. De URL verloopt na één uur en levert het bestand als bijlage. Gearchiveerde en onbekende documenten en documenten van een andere klant retourneren 404. Zie Mogelijkheden en vereisten.
• Het aanvragen van een mogelijkheid voor een bedrijf zonder uiteindelijk belanghebbende maakt nu een innametaak aan om er een toe te voegen, in plaats van te falen met een 503. Verzoeken die niet kunnen doorgaan retourneren 422 beneficial_owner_required met instructies om een individuele gerelateerde partij toe te voegen met opgegeven of ten minste 25% eigendom. Zie Aandeelhouders, UBO’s en controlepersonen.
• De takentabel van het merchantpanel toont nu het onderwerp en het mogelijkheidsbereik van elk verzoek, zodat je ziet wie en wat een compliance-verzoek dekt. Zie Mogelijkheden en vereisten.
• Velden voor brancheclassificatie in het merchantpanel bieden nu doorzoekbare NAICS-codes op klantprofielen en vereistetaken. Zie KYB-workflow.
• Pay-in-instructies voor banken kunnen bankName, bankAddress, accountHolderName en accountHolderAddress bevatten. Toon ze samen met de andere bankgegevens. Zie Geld ontvangen.
• POST /v3/transfers accepteert een optionele redirectUrl die de klant na een gehoste checkout met kaart of Apple Pay terugstuurt naar je app. Aankomst op de URL bevestigt de voltooiing niet; gebruik transfer-reads of webhooks. Zie Geld ontvangen.
• Transfers die door een v3-Rule zijn aangemaakt, verschijnen in transfer-reads en -lijsten met origin: rule en versturen transfer.state_changed-gebeurtenissen zoals andere transfers. Filter ze met GET /v3/transfers?origin=rule. Zie Quotes en transfers.
• Identiteitsdocumenten van klanten en gerelateerde partijen accepteren sideApplicability (front_only, front_and_back of unknown), en taken kunnen gegevens van identiteitsdocumenten zoals type, number, issuingCountry, issuingRegion, issuedOn, expiresOn en doesNotExpire als antwoorden verzamelen. Zie Mogelijkheden en vereisten.

​

Gewijzigd

• Indieningen van bankgegevens die conflicteren met een lopende bankconfiguratie retourneren nu 409 ops_rail_handoff_conflict. Bewaar je geüploade document-ID’s en dien dezelfde indiening opnieuw in nadat het conflict is opgelost, in plaats van documenten opnieuw te uploaden. Zie Fouten en nieuwe pogingen.
• Het minimum voor onaangekondigde stablecoin-stortingen in klantwallets is nu 1 eenheid in plaats van 10. Kleinere stortingen worden nog steeds als dust behandeld. Zie Geld ontvangen.
• De webhookconfiguratie is nu per omgeving geïsoleerd. Het webhookportaal opent beperkt tot de omgeving waaruit je het aanvraagt, zodat sandbox- en productie-endpoints geen instellingen meer delen. Zie Webhooks.
• Het merchantpanel leidt beschikbare pay-in-methoden nu af van de v3-mogelijkheden van de klant, zodat de rekeningconfiguratie alleen methoden aanbiedt waartoe de klant gerechtigd is. Zie Rekeningen.
• RFI-formulieren verzamelen kwalificerende uiteindelijk belanghebbenden nu met kortere, duidelijkere vragen, en de RFI-geschiedenis wordt weergegeven als levenscyclusmijlpalen. Zie Documentvereisten.
• Open taken zonder expliciete vervaldatum krijgen nu standaard een dueAt van 31 dagen na aanmaak. Zie Mogelijkheden en vereisten.

​

Verwijderd

• Het merchantpanel biedt niet langer Fedwire aan bij het toevoegen van nieuwe pay-in-methoden. Bestaande Fedwire-rekeningen blijven leesbaar. Zie Rekeningen.

​

Opgelost

• Onaangekondigde USDT-stortingen in klantwallets worden nu herkend en verwerkt in plaats van genegeerd.
• Bewijs dat je al hebt ingediend, wordt nu overgenomen naar andere taken die hetzelfde item vereisen, zodat klanten niet twee keer om hetzelfde document worden gevraagd.
• Het opnieuw aanvragen van een mogelijkheid verwijdert geen bankroutes meer die al gereed zijn, zodat uitgegeven rekeninggegevens stabiel blijven.
• Bankinstructieweergaven in het merchantpanel tonen nu volledige details, inclusief SWIFT-adressen en het doelwalletadres.
• RFI-formulieren tonen nu validatiefouten bij het indienen, valideren beschrijvingen van de rechtsvorm vóór het indienen en accepteren meerdere bedrijfswebsites.
• Je kunt concepten van gerelateerde personen in RFI-formulieren nu bewerken voordat je ze indient.
• Geannuleerde compliance-verzoeken verschijnen niet langer in de takenlijst van het merchantpanel.
• Documentbeoordelingsstatussen worden weer correct weergegeven in het merchantpanel.

​

Toegevoegd

• Gehoste verificatie- en Servicevoorwaarden-sessies binnen een klant bevatten nu een gezaghebbend action-object. Volg het type available of unavailable; de platte velden url en expiresAt blijven compatibiliteitsspiegels voor beschikbare acties. Zie Mogelijkheden en vereisten.
• Sandbox-walletopwaarderingen retourneren nu overdrachts-ID’s die je kunt ophalen met GET /v3/transfers/{transferId} of vermelden met GET /v3/transfers. Ze verschijnen als voltooide inkomende stablecoin-stortingen. Zie Testen in de sandbox.
• Reads van overdrachten bevatten een correction-object wanneer de middelen van een overdracht na voltooiing worden teruggestort of teruggedraaid. Het vermeldt de kind van de correctie, de genormaliseerde providerStatus, een eventuele providerShortfall en de compensatingIntent die Swipelux toepast. Zie Offertes en overdrachten.

​

Gewijzigd

• De First pay-in-wizard in het merchantpanel voor kaarten en Apple Pay vereist nu een Polygon-wallet onder de klant. Maak die wallet aan voordat je de wizard start. Zie Rekeningen.
• Nieuwe verzoeken en openbare antwoorden gebruiken sepa als canonieke naam voor de methode en mogelijkheid. De invoeralias sepa_instant en eerder opgeslagen resources blijven compatibel, maar openbare antwoorden gebruiken sepa. Zie Rekeningen.
• Nieuwe Faster Payments-verzoeken voor mogelijkheden, uitgegeven rekeningen en offertes zijn niet beschikbaar. Bestaande rekeningen, offertes en overdrachten blijven leesbaar. Zie Rekeningen.
• De eerste KYB-pagina verzamelt niet langer de geboortedatum van de vertegenwoordiger. Geboortedata van aandeelhouders blijven een afzonderlijke vereiste. Zie KYB-workflow.
• RFI-documentverwijzingen accepteren nu naast image/jpeg ook de MIME-alias image/jpg. Zie Documentvereisten.
• De taakgeschiedenis in het merchantpanel toont nu een leesbaar auditspoor zonder revisietellers. Zie Mogelijkheden en vereisten.
• Offertes en overdrachten controleren nu de ondersteunde richtingen van de mogelijkheid voordat er geld wordt verplaatst. Een mogelijkheid gebruiken in een richting die ze niet ondersteunt, retourneert 422 capability_direction_unsupported, en verplaatsingen tussen wallets vereisen een stablecoin_transfers-mogelijkheid. Zie Fouten en nieuwe pogingen.

​

Verwijderd

• Het merchantpanel biedt niet langer de configuratie van nieuwe UAEFTS-rekeningen aan. Bestaande UAEFTS-rekeningen blijven leesbaar. Zie Rekeningen.

​

Opgelost

• RFI-formulieren behouden bestaande invoer wanneer een beoordelaar een nieuw documentveld toevoegt, zodat eerdere antwoorden bij opnieuw indienen niet verloren gaan.
• Het merchantpanel hervat gehoste compliance-sessies vanuit beschikbare acties zonder geldige links te verwijderen.
• Gehoste links naar de Servicevoorwaarden werken nu voor elk taakbereik dat de API retourneert.
• Nadat je Payment Access in het merchantpanel aanvraagt, opent het de innametaak die door dat verzoek is geretourneerd in plaats van een taak uit een eerder verzoek.
• De KYB-demo in het merchantpanel vraagt nu om de huidige verplichte velden.
• Een offerte die de bronwallet opnieuw als destinationId gebruikt, retourneert nu bruikbare 422 quote_direction_invalid-details voordat providerwerk begint. Zie Offertes en overdrachten.
• De API weigert onjuist gecodeerde querystrings met een 400-fout in plaats van het verzoek stilzwijgend te normaliseren. Zie Fouten en nieuwe pogingen.
• POST /v3/customers/{customerId}/documents weigert nu lege, niet-multipart of onjuist opgemaakte request bodies met een 400-fout.

​

Toegevoegd

• De v3 Problem Details-catalogus gepubliceerd in de OpenAPI-spec, zodat integrators foutresponses rechtstreeks vanuit het schema kunnen mappen. Zie Errors.
• customerId toegevoegd aan v3 account-webhookevents, zodat je accountactiviteit kunt correleren aan de eigenaar-klant zonder een vervolg-read. Zie Webhooks.
• Volledige V3 individuele-profielvelddekking in het merchant panel, zodat onboarding-operators elk KYC-veld dat via de v3 API is verzameld kunnen bekijken en bewerken. Zie Klanten onboarden.
• Een v3 developer-migratiegids gepubliceerd. Zie Migreren naar v3.

​

Gewijzigd

• Landcodes van klanten en accounts worden bij het schrijven nu gevalideerd als toegewezen ISO 3166-1 alpha-2-waarden. Reads tolereren legacy opgeslagen waarden zodat bestaande records blijven resolven. Zie Accounts en wallets.
• USDC-beschikbaarheid is nu gescoped per bestemmingsnetwerk, zodat quotes en transfers alleen USDC aanbieden op netwerken die de bestemming daadwerkelijk ondersteunt.
• Elke onboardingflow vereist nu de Servicevoorwaarden van Swipelux. Bestaande sessies blijven hervatbaar. Zie Klanten onboarden.
• Capability.ready blijft de goedkeuring van de bevoegdheid rapporteren. Gebruik accountProvisioning om de accountuitgifte te volgen als not_applicable, not_started, in_progress, issued of failed. Zie Mogelijkheden en vereisten.
• HEIC-uploads vanaf iPhone worden nu geaccepteerd als identiteits- en adresdocumenten.
• Het leegmaken van een klant- of related-party-veld dat een open taak nog vereist, retourneert nu 409 field_required_by_open_task met de blokkerende taskId en fields, in plaats van een conflict dat opnieuw kan worden geprobeerd. Voltooi of annuleer de taak voordat je die velden wijzigt. Zie Fouten en nieuwe pogingen.

​

Opgelost

• Het opnieuw uitvoeren van een verbruikt quote retourneert nu 409 quote_execution_consumed in plaats van een generieke fout. Zie Quotes en transfers.
• Reads van transferlijsten en quote-bedragen geven bij grote historische resultaten geen 500 meer.
• Gelijktijdige KYC-redirects retourneren nu een conflict in plaats van 404, zodat retries netjes worden afgehandeld. Gehoste redirects rollen niet langer halverwege terug en KYC-links blijven hervatbaar.
• Related-party reads voor individuele klanten geven geen 404 meer.
• KYB-submissions met ongeldige walletvelden worden vóór indiening geweigerd, en mislukte synchronisatie wordt in het merchant panel niet langer als succes gerapporteerd.
• Requirement-taken in het merchant panel tonen ingediende antwoorden nu als voltooid, volgen terms-acties afzonderlijk, verwijderen dubbele documentteksten, houden gestarte KYC-sessies in behandeling tot voltooiing en verwerken verouderde taken zonder de requirements-view te breken.
• Rijen met verificatielinks in het merchant panel tonen nu op elke rij een Open-actie, en elke tasklink wordt in de requirements-view weergegeven.