Swipelux API endringslogg og versjonsmerknader

​

Lagt til

• Mottakerdestinasjoner godtar typene pix og pix_safe for BRL-payouts i Brasil. En Pix-destinasjon betaler til en Pix-nøkkel. En Pix Safe-destinasjon betaler til en bankkonto som identifiseres med innehaverens CPF eller CNPJ, bankens ISPB-kode, filialen og kontonummeret. Begge krever kundens klare Pix-funksjon (pix_pooled), og payouts til dem finansieres med USDC og har ikke noe utviklergebyr. Se Mottakere og Send midler.
• GET /v3/customers/{customerId}/tasks/{taskId} godtar documentCandidatesFor med en dokumentkrav-ID, pluss documentAlternativeKey for et krav med alternativer. Responsen lister da opp, i data.documentCandidates, filer kunden allerede har lastet opp som kan oppfylle kravet, med eventuelle missingMetadata eller conflictingMetadata. Send inn en kandidats documentId med manglende documentMetadata i stedet for å laste opp filen på nytt. Spørringen krever accounts:read og customers:read, og et ugyldig valg returnerer 400 validation_error.

​

Endret

• GET /v3/webhooks/portal returnerer en portal-URL som utløper etter én time, med Cache-Control: no-store. Med en API-nøkkel som har webhooks:write, viser portalen endepunktets signeringshemmelighet og kan administrere endepunkter, prøve leveranser på nytt og spille dem av på nytt. Med bare webhooks:read viser portalen kun leveranser. Se Webhooks.
• Citi (citibank) tilbys bare til bedriftskunder. Alle bedrifter beholder pooled Citi, og named Citi tilbys bare til bedrifter registrert utenfor USA. Når en kunde ikke tilbys Citi, utelater listen over støttede banker den, å angi den returnerer 422 capability_institutions_unsupported, og en metode som bare Citi tilbyr, vises som disabled. En forespørsel uten institutions velger blant de gjenværende bankene. Eksisterende søknader og kontoer er uendret.
• Named CFSB-funksjoner (cfsb) tilbys bare til amerikanske kunder: bedrifter registrert i USA og privatpersoner bosatt der. For andre kunder utelater listen over støttede banker named CFSB, og å angi den returnerer 422 capability_institutions_unsupported. En forespørsel uten institutions velger blant de gjenværende bankene. Pooled CFSB, kunder med ukjent land og eksisterende søknader er uendret.
• Named ACH-, Wire- og SWIFT-funksjoner hos Lead Bank (lead_bank) tilbys bare til kunder som Lead Bank kan onboarde, basert på selskapsform og land. For andre kunder utelater listen over støttede banker lead_bank, og å angi den returnerer 422 capability_institutions_unsupported. Kunder som Lead Bank allerede har onboardet, og funksjoner der den åpne forespørselen allerede angir lead_bank, beholder den. Eksisterende søknader og kontoer er uendret.
• RTP er bare pooled. Ingen bank tilbyr rtp_named for nye forespørsler, så listen over støttede funksjoner viser den som disabled. For en kunde som ikke har rtp_named, returnerer en forespørsel om funksjonen eller en forhåndsvisning av oppgavene for den 422 capability_institutions_unsupported hvis den angir en bank, og 422 capability_variant_unavailable hvis den ikke har institutions. Pooled RTP (rtp_pooled) tilbys hos Citi, så bare bedriftskunder kan be om den.
• Nye forespørsler om identitetsdokumenter for privatpersoner og reelle rettighetshavere kan angi constraints.identityMetadataRequired: true, slik at hver fil trenger ID-nummer og utstedende land i documentMetadata. Nye forespørsler om adressebevis for bedrifter og bostedsbevis for eiere kan angi constraints.maxIssueAgeDays: 90, slik at hver fil trenger utstedelsesdato. Eksisterende oppgaver beholder sine krav, så les begrensningene på hver oppgaveforespørsel.
• Et oppgavesvar på en forespørsel om bedriftsregistrering, der profilePointer er /business/registration, trenger jurisdiksjonslandet, registreringsnummeret og en stiftelsesdato før innsendingsdatoen, alt samlet. Forespørselens valueSchema publiserer denne regelen, og et delvis svar returnerer 400 validation_error.
• Etter en hostet verifisering godtar Swipelux et hostet svar på et profilkrav for en strukturert verdi, for eksempel en adresse eller skatteidentifikatorer, bare når det består de samme skjema- og begrensningskontrollene som et direkte svar. Ellers forblir kravet åpent, og du sender inn verdien med POST /v3/customers/{customerId}/tasks/{taskId}/submissions. Et krav som Swipelux returnerer til action_required av denne grunnen, har reviewFeedback.code: hosted_profile_direct_submission_required. Oppgaver som allerede er satisfied, beholder statusen sin. Se Funksjoner og krav.
• En oppgave som er avvist av en hostet verifisering, kan forlate rejected når verifiseringsbeslutningen senere omgjøres. Den blir da satisfied, eller action_required under en ny revision der kravene som den nye beslutningen ikke besvarer, er åpnet på nytt. Tidligere innsendinger for disse kravene forblir rejected, så send inn disse svarene på nytt. Se Migrere til v3.
• type for mottakerdestinasjoner er nå en åpen enum. Tidligere versjoner av denne referansen beskrev den som lukket, så oppdater enhver klient som avviser eller forkaster ukjente typer. Destinasjonsresponser og destination.status_changed-hendelser kan nå inneholde pix og pix_safe, og flere typer kan bli lagt til.
• Forespørsler om å opprette og oppdatere mottakere, inkludert den nestede address, ignorerer felt de ikke definerer, i stedet for å returnere 400 validation_error. I en opprettelsesforespørsel returnerer et navne- eller bransjefelt for den andre mottakertypen fortsatt 400, og det samme gjør type og externalId i PATCH /v3/customers/{customerId}/recipients/{recipientId}. En PATCH uten noe felt den gjenkjenner, returnerer 400 validation_error i stedet for 200.
• En verifiseringslenke for en kvalifisert økt som bare ber om dokumenter, åpner nå en dokumentopplastingsside som driftes av Swipelux. Selve lenken er uendret, og andre økter åpner fortsatt den hostede verifiseringsflyten.
• employment.occupation på privatkunder og personer som er relaterte parter, godtar maksimalt 255 tegn.
• POST /v3/customers, PATCH /v3/customers/{customerId}, POST /v3/customers/{customerId}/related-parties, PATCH /v3/customers/{customerId}/related-parties/{relatedPartyId} og POST /v3/customers/{customerId}/tasks/{taskId}/submissions returnerer 400 validation_error når en profilverdi eller et oppgavesvar inneholder en Swipelux-skjemalenke, for eksempel en RFI-, kundeforespørsels- eller overføringssporingslenke. Dette gjelder ikke externalId eller metadata. Hver avvist verdi vises i errors[] med code: public_form_link og sin JSON Pointer, og svaret gjentar aldri lenken. Send i stedet selve informasjonen. Se Feil og nye forsøk.

​

Rettet

• Responser for payout-tilbud og overføringer beholder et kildebeløp i USDC eller USDT med seks desimaler, for eksempel 4009.711365 i stedet for 4009.71. Fiat-beløp beholder to desimaler. Å opprette eller lese en payout der kildebeløpet i stablecoin har mer enn to desimaler, returnerer ikke lenger 500.
• Referansen for POST /v3/customers/{customerId}/capabilities/{capabilityId}/cancel beskriver nå kansellering slik den faktisk fungerer. Du kan kansellere en funksjon med status ready, funksjonen stablecoin_transfers kan ikke kanselleres, og kansellering avslutter bare den funksjonen, mens søknadene beholder sin status, sine oppgaver og godkjenninger.
• En forespørsel om en funksjon eller en forhåndsvisning av oppgaver som angir en bankkode i institutions i stedet for en offentlig institusjons-ID, for eksempel citi for citibank, returnerer 422 capability_institutions_unsupported med de tilgjengelige ID-ene i stedet for 503 kyc_configuration_unavailable.
• En forespørsel om en funksjon eller en forhåndsvisning av oppgaver for en metode som ingen bank tilbyr kunden, og som listen over støttede funksjoner viser som disabled, returnerer 422 capability_variant_unavailable med retryable: false i stedet for 503 kyc_configuration_unavailable, med mindre kunden allerede har funksjonen.
• documentCandidates lister ikke lenger opp filer som Swipelux beholder fra en fullført hostet verifisering, og som du ikke kan lese eller laste ned. Et oppgavesvar som viser til en slik fil, returnerer 400 invalid_document_reference, slik et ukjent dokument gjør.

​

Lagt til

• GET /v3/customers godtar include=documentRequirements. Hvert kundesammendrag rapporterer da hvor mange obligatoriske dokumenter som fortsatt mangler, uavhengig av funksjonsberedskap. Kombiner det som include=capabilities,documentRequirements. Se Kunder.
• Webhooks-siden i forhandlerpanelet legger til Replay missed events i endepunktmenyen. Den sender på nytt hendelser fra de siste 13 dagene som endepunktet aldri mottok, og sender aldri den samme hendelsen to ganger. Se Webhooks.
• Settings-siden i forhandlerpanelet har en Compliance-seksjon. Eiere og administratorer kan angi e-postadressen for samsvar og velge om de vil motta e-post når Swipelux ber om mer informasjon om en kunde.
• Forhandlere kan svare på sine egne KYB-samsvarsforespørsler direkte på KYB-siden i forhandlerpanelet.

​

Endret

• Oppdateringer av kunder og relaterte parter returnerer ikke lenger 409 field_conflicts_with_completed_intake etter et fullført bankinntak. Oppdateringen lagres, og hver ny banksøknad kontrollerer den nyeste profilen mot sine egne krav.
• Forespørsler om funksjoner returnerer 409 capability_route_header_conflict når den eksisterende bankrutingen for en funksjon ikke kan oppdateres trygt. Kontakt Swipelux-støtte før du prøver igjen.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview returnerer 422 capability_institutions_unsupported når institutions angir en bank som funksjonen ikke tilbyr, slik forespørsler om funksjoner allerede gjør.
• I sandbox tilbys ACH-, Wire- og SWIFT-funksjoner bare hos JPMorgan Chase. Forespørsler som utelater institutions, velger jpmorgan, og å angi en annen bank returnerer 422 capability_institutions_unsupported. Live-ruting er uendret. Se Test i sandbox.
• Å tvinge statusen til en funksjon i sandbox returnerer 409 capability_status_blocked med en statusReason når det simulerte tilfellet ikke kan nå den forespurte statusen. Å gjenta en tvungen status som allerede er brukt, returnerer 200 uendret. Se Test i sandbox.
• POST /v3/sandbox/tasks/{taskId}/review returnerer 409 task_not_sandbox_reviewable for en oppgave som eies av Operations eller en annen arbeidsflyt. Oppgaver fra POST /v3/sandbox/tasks og capability-mottaksoppgavene som Swipelux samler inn, kan fortsatt gjennomgås. Se Test i sandbox.
• PATCH /v3/customers/{customerId}/accounts/{accountId} returnerer 409 account_provisioning_unresolved når du endrer oppgjør mens kontoen fortsatt klargjøres hos banken. Prøv på nytt når klargjøringen er avklart. Se Feil og nye forsøk.
• POST /v3/transfers kan returnere 409 quote_execution_evidence_conflict. Opprett et nytt tilbud og utfør det. Se Feil og nye forsøk.
• Pay out-skuffen i forhandlerpanelet viser fullstendige destinasjonsdetaljer, skjuler kontonumre og lommebokadresser bak en bryter og viser en estimert ankomsttid for hver betalingsmetode.
• Forhandlerpanelet samler bankkontoer i kundens Payment access-fane, med et oppgavekort som navngir hver bank. Documents-fanen er flyttet til Profile.
• Å åpne en navngitt bankkonto i forhandlerpanelet er nå ett enkelt trinn som viser hver banks valuta, metoder og onboardingtid. Se Kontoer.
• Bankkontoer som holdes tilbake for gjennomgang, vises som On hold i forhandlerpanelet, med konto-ID-en og en Contact support-handling.
• En pending capability rapporterer nå statusReason.code: preparing_submission i stedet for review_in_progress mens Swipelux forbereder en søknad for innsending og ingen gjennomgang pågår. Begge kodene bruker resolution: wait. En endring mellom dem beholder statusen pending, så det sendes ingen capability.status_changed-hendelse. Eksisterende capabilities får den nye koden ved neste reevaluering. Se Funksjoner og krav.
• Tabellen Shared methods på kundens Payment access-fane i forhandlerpanelet viser In preparation i stedet for In review for en delt metode der capability-en rapporterer preparing_submission.
• En capabilitys applications-liste viser nå bare de gjeldende søknadene, i capability-lesinger (inkludert GET /v3/customers/{customerId}/capabilities/{capabilityId}/applications), svar på capability-forespørsler og capability.status_changed-hendelser. En søknad som en nyere har erstattet, vises fortsatt i GET /v3/customers/{customerId}/applications, der supersededByApplicationId angir etterfølgeren. Åpne oppgaver for en erstattet søknad telles fortsatt i capability-ens openTaskIds. Capability-ens status og openTaskIds endres ikke, så selve endringen sender ingen webhook-hendelse. Se Funksjoner og krav.

​

Rettet

• En ny allowPending-forespørsel for den samme utstedte kontoen, sendt før banken godkjenner, returnerer 409 med den ventende kontoen i holder.accountId i stedet for 500. Se Utsted en bankkonto.
• Å kansellere en funksjon lukker nå forespørsler om utstedte kontoer som fortsatt ventet på godkjenning fra banken, slik at en senere forespørsel hos den samme banken starter på nytt.
• Å be på nytt om en kansellert funksjon der alle banksakene ble avvist, publiserer én enkelt capability.status_changed-hendelse fra canceled.
• Å be om en bank på nytt etter at den tidligere søknaden ble arkivert, sender nå inn den nye søknaden.
• Mottakerdestinasjoner kan legges til så snart den tilhørende funksjonen er ready, i stedet for å returnere 409 rail_not_ready. Se Mottakere.
• Webhook-hendelser sendt før du første gang åpner Webhooks-siden i forhandlerpanelet, beholdes nå, slik at du kan sende dem på nytt til et nytt endepunkt.
• Forfallsdatoer for oppgaver i forhandlerpanelet vises i din egen tidssone, og skuffer for bankgjennomgang viser All requirements submitted når ingenting gjenstår.

​

Lagt til

• POST /v3/quotes godtar en valgfri institutionId for å velge en godkjent bankrute for et tilbud på en utbetaling fra krypto til fiat. Utelat den for å beholde automatisk ruting. En bank som ikke er tilgjengelig for utbetalingen, returnerer 422 bank_not_supported_for_customer, og å sende institutionId med en hvilken som helst annen tilbudstype returnerer 400 validation_error. Se Send midler.
• Forespørsler om utstedte bankkontoer på POST /v3/customers/{customerId}/accounts godtar institution for å låse kontoen til én bank uten reserveløsning, og allowPending: true for å lagre forespørselen mens søknaden hos den banken fortsatt venter på godkjenning. allowPending krever institution. Lagrede forespørsler oppgir den styrende applicationId. Se Utsted en bankkonto.
• Forhandlerpanelet har en innebygd Webhooks-side for administrasjon av endepunkter. Se Webhooks.
• Forhandlerpanelet legger til en Pay in-skuff med navngitte bankkontoer, kryptoinnskudd og et gjennomgangstrinn.
• Pay out-flyten i forhandlerpanelet viser lommeboksaldoer i kildevelgeren, legger til et beløpsalternativ Max og inkluderer et gjennomgangstrinn.
• Kundeprofiler i forhandlerpanelet har en Recipients & destinations-fane.
• Oppgavekrav kan inneholde en kort title-overskrift. Forespørselens prompt inneholder fortsatt veiledningen. Se Funksjoner og krav.

​

Endret

• Tilbud på wire-pay-ins på delte (pooled) Wire-ruter krever nå minst $20. Tilbud under en rutes minimum, eller som er for små til å dekke overføringsgebyrer, returnerer 422 amount_not_deliverable i stedet for en generell tilbudsfeil. Se Motta midler.
• Webhook-portalen grupperer nå v3-hendelsestyper etter ressurs og viser payload-skjemaet og et eksempel for hver hendelse. Eldre hendelsestyper vises i en egen Legacy-gruppe og er merket som utfaset. Endepunkter som allerede abonnerer på dem, fortsetter å motta dem; bruk v3-hendelsestyper for nye abonnementer. Se Webhooks.
• Påfyll i sandbox sender nå webhook-hendelsene transfer.created og transfer.state_changed. Se Test i sandbox.
• accountProvisioning rapporterer nå issued når kunden allerede har en aktiv utstedt konto. Se Funksjoner og krav.
• Bankkontodetaljer i forhandlerpanelet åpnes i en skuff med banklogoer. Se Kontoer.
• Forhandlerpanelet merker pengebevegelser som Pay in og Pay out, holder deg innlogget i seks timer og sender hjelpeforespørsler til Swipelux-support på e-post.
• I inntaksoppgaver som godtar direkte innsending, flyttes kvalifiserte krav som allerede støttes av kundeprofilen eller opplastede dokumenter, automatisk til in_review. Se Funksjoner og krav.

​

Rettet

• Å be om en kansellert funksjon på nytt feiler ikke lenger på grunn av erstattede søknadsoppføringer eller utdaterte krav.
• Funksjoner lagret under den utfasede Fedwire-ID-en leses nå som wire i stedet for å returnere 500.

​

Lagt til

• GET /v3/customers/{customerId}/applications lister en kundes søknadssaker, med funksjonene som er forespurt for hver sak og funksjonene godkjenningen dekker. Én godkjenning hos en bank kan dekke flere funksjoner. Bevarte historiske saker peker til sin etterfølger gjennom supersededByApplicationId. Listen støtter markørbasert paginering og updatedAfter. Se Funksjoner og krav.
• Svar fra POST /v3/customers/{customerId}/capabilities/{capabilityId} inkluderer selectedApplicationId for saksbaserte funksjoner. Det identifiserer den eksisterende søknadssaken forespørselen gjenbrukte, eller saken den åpnet. Se Funksjoner og krav.
• Institusjoner som returneres av GET /v3/institutions og av listen over støttede funksjoner, inkluderer en logoUrl som kan være null. Bruk den til å vise bankens merkevare når den er tilgjengelig, og fall tilbake til institusjonens navn når den er null. Se Funksjoner og krav.
• USD SWIFT-utbetalinger er nå tilgjengelige. SWIFT-utbetalinger krever minst 100 USD. Forhandlerpanelet samler inn SWIFT-bankinstruksjoner for mottakere. Se Send midler.
• Utstedte bankkontoer kan motta over SWIFT med navngitte mottaksdetaljer. Se Utsted en bankkonto.
• USDT støttes nå som kilde for ACH- og Wire-utbetalinger. Se Send midler.
• Utstedte bankkontoer godtar settlement.currency med USDC eller USDT for å velge hvilken stablecoin som leveres til oppgjørslommeboken, uavhengig av lommebokkontoens valuta. Utelat den for å fortsette å gjøre opp i lommebokens valuta. Se Utsted en bankkonto.
• SWIFT-bankkontoer og mottakerdestinasjoner godtar bankCity, bankState, bankPostalCode og bankAddressLine2, i tillegg til valgfrie beneficiaryTaxId, beneficiaryPhoneNumber, ifscBranchCode, paymentCode og detaljer om mellombank. Se Send midler.
• Detaljer for utstedte bankkontoer inkluderer achRoutingNumber og wireRoutingNumber når banken oppgir separate ACH- og Wire-rutingnumre, og bankLogoUrl for den mottakende banken. Se Utsted en bankkonto.
• Webhook-hendelsene capability.created inkluderer applicationId og en origin med verdien requested eller approval, slik at du kan skille funksjoner du ba om fra funksjoner som en godkjenning dekket. Se Webhooks.
• Kravforespørsler kan angi et valideringsformat i constraints.format, for eksempel http_url, us_ssn, us_ein eller bank_industry_classification. Se Funksjoner og krav.

​

Endret

• Oppretting av bankkonto i forhandlerpanelet starter nå med valg av bank, og bankkontoer viser separate ACH- og Wire-rutingnumre. Se Kontoer.
• Enumen network inkluderer nå solana. Det er en åpen enum, så tål nettverksverdier du ikke kjenner igjen. Se Kontoer.
• Å åpne en vertsbasert verifiseringslenke for en oppgave der de gjenværende kravene krever direkte innsending, returnerer 409 verification_session_not_allowed. Send inn disse kravene som en oppgaveinnsending i stedet. Se Feil og nye forsøk.
• Å arkivere en utstedt konto der klargjøringen ikke er avklart, returnerer 409 account_provisioning_unresolved. Prøv på nytt når klargjøringen er avklart. Se Feil og nye forsøk.
• Nye forespørsler om navngitte bankkontoer settes i kø for klargjøring så snart kontoen opprettes, i stedet for å vente på neste kundeoppdatering. Se Utsted en bankkonto.

​

Fjernet

• Delte (pooled) SWIFT-mottaksdetaljer tilbys ikke lenger for nye kontoer. Bruk navngitte SWIFT-mottaksdetaljer i stedet. Se Utsted en bankkonto.

​

Rettet

• Lesing av utbetalingsoverføringer returnerer nå mottakeren fra tilbudet.
• Å opprette en ACH-konto etter å ha arkivert en eksisterende returnerer ikke lenger 409, og arkiverte ventende kontoforespørsler opptar ikke lenger en kontoplass.
• Bankgebyrer på pay-in-tilbud i lokal valuta rapporteres i riktig fiatvaluta.

​

Lagt til

• GET /v3/webhooks/{webhookId} leser ett enkelt webhook-endepunkt og dets events-utvalg. Se Webhooks.
• Oppgavekrav publiserer nå allowedValues og et JSON Schema-valueSchema for profilfelt, inkludert påkrevde adressefelt. Landfelt oppgir valueType eller itemValueType med verdien country, som betyr en ISO 3166-1 alpha-2-kode. Du kan gjengi inndatafelt og valg uten å hardkode dem. Se Funksjoner og krav.
• Eksisterende Tron-lommebøker kan nå sende USDT til kundens eksterne lommebokkontoer, og lesing av overføringer inkluderer en lenke til en blokkutforsker for Tron-transaksjoner. Nye lommebøker kan ikke utstedes på Tron. Se Send midler.
• Oppgavekrav kan angi requiredWhen (svar bare når et navngitt ja/nei-svar samsvarer), profileAssertion (us_person) og ownershipPolicy, og dokumentforespørsler kan angi identityMetadataRequired og maxIssueAgeDays. Oppgavesvar godtar documentMetadata (idNumber, issuingCountry, issuedOn) for refererte dokumenter, og lesing av oppgaver returnerer gjennomgåtte styrende svar i conditionValues. Se Funksjoner og krav.
• Dokumentkrav kan liste opp acceptedDocumentSets, og krav til relaterte parter kan be om kvalifikasjonen associated_person eller control_person i tillegg til beneficial_owner. Se Funksjoner og krav.
• correction-objekter på overføringer dekker nå også mislykkede finansierte utbetalinger: kind: funding_failure med den kompenserende handlingen recover_source_funding, en recoveryStatus med verdien unknown eller reported, og krediterte utdata i USDT. Se Tilbud og overføringer.

​

Endret

• PATCH /v3/webhooks/{webhookId} godtar nå eldre hendelsestyper som endepunktet allerede abonnerer på, slik at du kan beholde dem mens du legger til v3-hendelsestyper. events erstatter hele utvalget, så ta med alle hendelsestyper du vil beholde. Å legge til en eldre hendelsestype som endepunktet ikke allerede hadde, returnerer 400 validation_error. Se Webhooks.
• Bankidentifikatorer på mottakere og kontoer valideres før de lagres. Se Mottakere.
• Forespørsler om funksjoner, innsendinger av oppgaver og statusendringer i sandbox returnerer nå 409 capability_application_stale i stedet for 500 når en funksjon ble opprettet under en tidligere onboarding-modell. Se Feil og nye forsøk.
• Den offentlige RFI-siden er nå ett sammenhengende skjema. Den støtter relaterte personer og samler inn ett skatte-ID per person. Se Dokumentkrav.
• Tilbud og overføringer returnerer 409 customer_bank_limit_exceeded når en betaling overskrider kundens gjenværende daglige eller månedlige grense hos banken, og 503 customer_bank_limits_unavailable når grensen ikke kan kontrolleres. Overføringer returnerer 409 payout_execution_unavailable når en utbetaling ikke kan starte fra tilbudet sitt. Se Feil og nye forsøk.
• Oppdateringer av kunder og relaterte parter som er i konflikt med et fullført bankinntak, returnerer 409 field_conflicts_with_completed_intake med taskId og fields.

​

Rettet

• Historikken for kansellerte funksjoner forblir lesbar.
• Wire-utbetalinger vises og filtreres riktig i transaksjonslisten i forhandlerpanelet.

​

Endret

• POST /v3/transfers og lesing av overføringer bruker checkoutMethod i stedet for paymentMethod for forhåndsvalget i kort-checkouten, og godtar card, apple_pay, google_pay, cash_app, sepa og blik. Listen er åpen og kan vokse. paymentMethod gjenkjennes ikke lenger; forespørsler som fortsatt sender det, behandles som om det var utelatt. sepa og blik er betalingsalternativer inne i kort-checkouten, ikke Swipelux-kapabiliteter. Se Motta midler.

​

Lagt til

• POST /v3/transfers godtar en valgfri paymentMethod med verdien card, apple_pay eller google_pay for korttilbud. Den hostede checkouten åpnes med den forespurte metoden når den er tilgjengelig for kunden og enheten deres, lesing av overføringen returnerer forespørselen, og tilbudets beløp og gebyrer er uendret. Se Motta midler.
• GET /v3/customers/{customerId}/capabilities/{capabilityId}/tasks-preview godtar institutions for å forhåndsvise oppgavene for bestemte banker som returneres av listen over støttede funksjoner. Se Funksjoner og krav.

​

Endret

• Korttilbud gjenspeiler nå betalingsgebyrer og netto levert USDC. Se Motta midler.
• Avviste utbetalingstilbud returnerer en spesifikk problemkode i stedet for en generell feil: quote_amount_out_of_range, quote_volume_limit_exceeded, quote_source_network_unsupported eller quote_failed, og 503 quote_temporarily_unavailable når tilbudet kan prøves på nytt senere. Se Feil og nye forsøk.

​

Rettet

• Korttilbud feiler ikke lenger på grunn av avrunding av gebyrer.
• Å åpne en hostet KYC-lenke på nytt returnerer ikke lenger 409 kyc_process_conflict når spørreskjemasvar inneholder ekstra mellomrom.
• Fastlåste passkey-bekreftelser for uttak i forhandlerpanelet gjenopprettes nå.

​

Lagt til

• POST /v3/customers/{customerId}/documents godtar nå også en application/json-forespørselskropp med storageKey, fileName og type. storageKey må være en fersk kundeavgrenset referanse parkert gjennom den tidligere direct-upload-flyten, og opplastingen gjennomgår samme validering av størrelse og filsignatur som multipart-opplastinger. Se Migrere til v3.
• GET /v3/customers/{customerId}/documents/{documentId}/download returnerer en nedlastings-url for et aktivt kundedokument. URL-en utløper etter én time og serverer filen som et vedlegg. Arkiverte dokumenter, ukjente dokumenter og dokumenter som tilhører andre kunder returnerer 404. Se Funksjoner og krav.
• Å be om en funksjon for en virksomhet uten reell rettighetshaver oppretter nå en inntaksoppgave for å legge til en, i stedet for å feile med 503. Forespørsler som ikke kan fortsette, returnerer 422 beneficial_owner_required med instruksjoner om å legge til en individuell relatert part med erklært eierskap eller minst 25 % eierandel. Se Aksjonærer, UBO-er og kontrollpersoner.
• Oppgavetabellen i forhandlerpanelet viser nå subjektet og funksjonsomfanget for hver forespørsel, slik at du kan se hvem og hva en samsvarsforespørsel dekker. Se Funksjoner og krav.
• Bransjeklassifiseringsfelt i forhandlerpanelet tilbyr nå søkbare NAICS-koder på kundeprofiler og kravoppgaver. Se KYB-arbeidsflyt.
• Instruksjoner for bank-pay-in kan inkludere bankName, bankAddress, accountHolderName og accountHolderAddress. Vis dem sammen med de andre bankopplysningene. Se Motta midler.
• POST /v3/transfers godtar en valgfri redirectUrl som sender kunden tilbake til appen din etter en hostet betalingsside for kort eller Apple Pay. Ankomst til URL-en bekrefter ikke fullføring; bruk lesing av overføringer eller webhooks. Se Motta midler.
• Overføringer opprettet av en v3-regel vises i lesing og lister av overføringer med origin: rule og sender transfer.state_changed-hendelser som andre overføringer. Filtrer dem med GET /v3/transfers?origin=rule. Se Tilbud og overføringer.
• Identitetsdokumenter på kunder og relaterte parter godtar sideApplicability (front_only, front_and_back eller unknown), og oppgaver kan samle inn detaljer om identitetsdokumenter som type, number, issuingCountry, issuingRegion, issuedOn, expiresOn og doesNotExpire som svar. Se Funksjoner og krav.

​

Endret

• Innsendinger av bankdetaljer som er i konflikt med et pågående bankoppsett, returnerer nå 409 ops_rail_handoff_conflict. Behold dokument-ID-ene du har lastet opp, og prøv den samme innsendingen på nytt etter at konflikten er løst, i stedet for å laste opp dokumentene på nytt. Se Feil og nye forsøk.
• Minimumet for uannonserte stablecoin-innskudd til kundelommebøker er nå 1 enhet i stedet for 10. Mindre innskudd behandles fortsatt som støv. Se Motta midler.
• Webhook-konfigurasjonen er nå isolert per miljø. Webhook-portalen åpnes avgrenset til miljøet du ber om den fra, slik at sandbox- og produksjonsendepunkter ikke lenger deler innstillinger. Se Webhooks.
• Forhandlerpanelet utleder nå tilgjengelige pay-in-metoder fra kundens v3-funksjoner, slik at kontooppsettet bare tilbyr metoder kunden har rett til. Se Kontoer.
• RFI-skjemaer samler nå inn kvalifiserende reelle rettighetshavere med kortere og tydeligere spørsmål, og RFI-historikken vises som livssyklusmilepæler. Se Dokumentkrav.
• Åpne oppgaver uten eksplisitt forfallsdato får nå dueAt satt til 31 dager etter opprettelse som standard. Se Funksjoner og krav.

​

Fjernet

• Forhandlerpanelet tilbyr ikke lenger Fedwire når du legger til nye pay-in-metoder. Eksisterende Fedwire-kontoer er fortsatt lesbare. Se Kontoer.

​

Rettet

• Uannonserte USDT-innskudd til kundelommebøker gjenkjennes og gjøres nå opp i stedet for å bli ignorert.
• Bevis du allerede har sendt inn, overføres nå til andre oppgaver som krever det samme elementet, slik at kundene ikke blir bedt om det samme dokumentet to ganger.
• Å be om en funksjon på nytt forkaster ikke lenger bankruter som allerede er klare, slik at utstedte kontodetaljer forblir stabile.
• Bankinstruksjonsvisninger i forhandlerpanelet viser nå fullstendige detaljer, inkludert SWIFT-adresser og mållommebokadressen.
• RFI-skjemaer viser nå valideringsfeil ved innsending, validerer beskrivelser av juridisk form før innsending og godtar flere virksomhetsnettsteder.
• Du kan nå redigere utkast til relaterte personer i RFI-skjemaer før innsending.
• Kansellerte samsvarsforespørsler vises ikke lenger i oppgavelisten i forhandlerpanelet.
• Statuser for dokumentgjennomgang vises riktig igjen i forhandlerpanelet.

​

Lagt til

• Kundespesifikke, vertsbaserte verifiserings- og vilkårsøkter inneholder nå et autoritativt action-objekt. Følg typen available eller unavailable; de flate feltene url og expiresAt beholdes som kompatibilitetsspeil for tilgjengelige handlinger. Se Funksjoner og krav.
• Påfyll av sandbox-lommebøker returnerer nå overførings-ID-er som du kan lese med GET /v3/transfers/{transferId} eller liste med GET /v3/transfers. De vises som fullførte innkommende stablecoin-innskudd. Se Test i sandbox.
• Lesing av overføringer inkluderer et correction-objekt når midlene i en overføring returneres eller reverseres etter at den er fullført. Det oppgir korreksjonens kind, den normaliserte providerStatus, eventuell providerShortfall og compensatingIntent som Swipelux bruker. Se Tilbud og overføringer.

​

Endret

• First pay-in-veiviseren i forhandlerpanelet for kort og Apple Pay krever nå en Polygon-lommebok under kunden. Opprett lommeboken før du starter veiviseren. Se Kontoer.
• Nye forespørsler og offentlige svar bruker sepa som det kanoniske navnet på metoden og funksjonen. Inndataaliaset sepa_instant og tidligere lagrede ressurser forblir kompatible, men offentlige svar bruker sepa. Se Kontoer.
• Nye forespørsler om Faster Payments-funksjoner, utstedte kontoer og tilbud er ikke tilgjengelige. Eksisterende kontoer, tilbud og overføringer er fortsatt lesbare. Se Kontoer.
• Den første KYB-siden samler ikke lenger inn representantens fødselsdato. Aksjonærenes fødselsdatoer er fortsatt et eget krav. Se KYB-arbeidsflyt.
• RFI-dokumentreferanser godtar nå MIME-aliaset image/jpg i tillegg til image/jpeg. Se Dokumentkrav.
• Oppgavehistorikken i forhandlerpanelet viser nå et lesbart revisjonsspor uten revisjonstellere. Se Funksjoner og krav.
• Tilbud og overføringer kontrollerer nå funksjonens støttede retninger før penger flyttes. Å bruke en funksjon i en retning den ikke støtter, returnerer 422 capability_direction_unsupported, og flytting mellom lommebøker krever en stablecoin_transfers-funksjon. Se Feil og nye forsøk.

​

Fjernet

• Forhandlerpanelet tilbyr ikke lenger oppsett av nye UAEFTS-kontoer. Eksisterende UAEFTS-kontoer er fortsatt lesbare. Se Kontoer.

​

Rettet

• RFI-skjemaer beholder eksisterende oppføringer når en kontrollør legger til et nytt dokumentfelt, slik at tidligere svar ikke går tapt ved ny innsending.
• Forhandlerpanelet gjenopptar vertsbaserte samsvarsøkter fra tilgjengelige handlinger uten å forkaste gyldige lenker.
• Vertsbaserte lenker til vilkårene fungerer nå for alle oppgaveomfang som API-et returnerer.
• Etter at du ber om Payment Access i forhandlerpanelet, åpner det inntaksoppgaven som ble returnert av forespørselen, i stedet for en oppgave fra en tidligere forespørsel.
• KYB-demoen i forhandlerpanelet ber nå om de gjeldende obligatoriske feltene.
• Et tilbud som gjenbruker kildelommeboken som destinationId, returnerer nå handlingsrettede 422 quote_direction_invalid-detaljer før leverandørarbeid starter. Se Tilbud og overføringer.
• API-et avviser feil kodede spørringsstrenger med en 400-feil i stedet for å normalisere forespørselen i det skjulte. Se Feil og nye forsøk.
• POST /v3/customers/{customerId}/documents avviser nå tomme, ikke-multipart eller feilformaterte forespørselskropper med en 400-feil.

​

Lagt til

• Publisert v3 Problem Details-katalogen i OpenAPI-spesifikasjonen slik at integratorer kan mappe feilresponser direkte fra skjemaet. Se Errors.
• Lagt til customerId i v3 konto-webhook-hendelser, slik at du kan korrelere kontoaktivitet med den eiende kunden uten en oppfølgings-read. Se Webhooks.
• Full dekning av v3-individprofilfelt i merchant panel, slik at onboarding-operatører kan gjennomgå og redigere hvert KYC-felt som samles inn via v3 API-et. Se Onboard kunder.
• Publisert en v3 utvikler-migreringsguide. Se Migrere til v3.

​

Endret

• Landkoder for kunder og kontoer valideres nå som tildelte ISO 3166-1 alpha-2-verdier ved skriving. Reads tolererer eldre lagrede verdier slik at eksisterende poster fortsatt løses. Se Kontoer og lommebøker.
• USDC-tilgjengelighet er nå avgrenset etter destinasjonsnettverk, slik at tilbud og overføringer bare tilbyr USDC på nettverkene som destinasjonen faktisk støtter.
• Hver onboarding-flyt krever nå Swipelux’ Terms of Service. Eksisterende økter kan fortsatt gjenopptas. Se Onboard kunder.
• Capability.ready viser fortsatt at rettigheten er godkjent. Bruk accountProvisioning til å følge kontoutstedelsen som not_applicable, not_started, in_progress, issued eller failed. Se Funksjoner og krav.
• HEIC-opplastinger fra iPhone aksepteres nå som identitets- og adressedokumenter.
• Å tømme et felt på en kunde eller relatert part som en åpen oppgave fortsatt krever, returnerer nå 409 field_required_by_open_task med den blokkerende taskId og fields, i stedet for en konflikt som kan prøves på nytt. Fullfør eller kanseller oppgaven før du endrer disse feltene. Se Feil og nye forsøk.

​

Rettet

• Å kjøre en forbrukt quote på nytt returnerer nå 409 quote_execution_consumed i stedet for en generisk feil. Se Tilbud og overføringer.
• Reads av overføringslister og quote-beløp gir ikke lenger 500 på store historiske resultater.
• Samtidige KYC-omdirigeringer returnerer nå en konflikt i stedet for 404, slik at nye forsøk løses rent. Vertsbaserte omdirigeringer ruller ikke lenger tilbake midtveis, og KYC-lenker kan fortsatt gjenopptas.
• Related-party reads for individuelle kunder gir ikke lenger 404.
• KYB-innsendinger med ugyldige lommebokfelter avvises før innsending, og mislykket synkronisering rapporteres ikke lenger som vellykket i merchant panel.
• Kravoppgaver i merchant panel viser nå innsendte svar som fullførte, sporer vilkårshandlinger separat, fjerner duplisert dokumenttekst, holder påbegynte KYC-økter ventende til de er fullført, og håndterer foreldede oppgaver uten å ødelegge requirements-visningen.
• Rader med verifiseringslenker i merchant panel viser nå en Open-handling på hver rad, og hver oppgavelenke rendres i requirements-visningen.