Skip to main content
Capability vám říká, zda zákazník může využívat konkrétní výsledek, platební metodu a směr. Otevřené úkoly vám říkají, co se musí stát, než capability nebo související zdroj může postoupit.

Objevte podporované capabilities

Přečtěte aktuální možnosti zákazníka pomocí GET /v3/customers/{customerId}/capabilities/supported:
Vyberte položku odpovědi, která odpovídá zamýšleným directions, method a accountType. Pokračujte jen tehdy, když availability je available nebo beta a eligibility.eligible je true. Pokud jsou vráceny institutions, vyberte pouze ID z této odpovědi. Uložte vybrané data[].id jako CAPABILITY_ID. Nikdy nekopírujte ID capability od jiného zákazníka nebo z jiného prostředí.

Sdružené vs. pojmenované typy účtů

Bankovní capabilities přicházejí ve dvou variantách, kódovaných jako pole accountType a přípona ID capability (například ach_pooled, wire_named):
  • pooled: sdílený bankovní účet Swipelux. Každá příchozí platba používá unikátní referenci ke směrování prostředků. Zvolte pro jednorázové převody.
  • named: vyhrazené bankovní údaje pro zákazníka (virtuální IBAN, vyhrazený ACH účet). Opakovaně použitelné a sdílitelné s jakýmkoli plátcem. Vyžadováno pro vydané bankovní účty.
Výchozí volba je pooled. Používejte named pouze tehdy, když zákazník potřebuje opakovaně použitelné bankovní údaje. Zkontrolujte odpověď supported, které varianty jsou k dispozici.

Požádejte o capability

Požádejte o vybranou možnost pomocí POST /v3/customers/{customerId}/capabilities/{capabilityId}:
Explicitní pole institutions používejte pouze tehdy, když potřebujete vybrat z ID vrácených v odpovědi na podporované capabilities. Uložte data.status jako CAPABILITY_STATUS, data.openTaskIds jako OPEN_TASK_IDS a každé data.applications[].id do APPLICATION_IDS.

Dokončete aktuální úkoly

Zjistěte úkoly pomocí GET /v3/customers/{customerId}/tasks, vyberte ID z OPEN_TASK_IDS, poté přečtěte každý aktuální úkol pomocí GET /v3/customers/{customerId}/tasks/{taskId}:
Použijte nejnovější data.revision a data.requirements. Znovu načtěte úkol bezprostředně před odesláním, pokud se některé z nich mohlo změnit. Každý otevřený úkol obsahuje časové razítko dueAt. Když Swipelux vytvoří úkol bez explicitního data splatnosti, nastaví se dueAt výchozím způsobem přesně na 31 dní po createdAt úkolu. Berte dueAt jako informativní: nelze jej nastavit přes API a nespouští žádný automatický přechod životního cyklu. Pouze samostatné pole deadline, pokud je nastaveno, způsobí automatický přechod.

Hostované akce

V odpovědi s detailem úkolu obsahuje každá položka v verificationSessions a tosSessions objekt action. Odpovědi se seznamem úkolů tyto odkazy na akce neobsahují. Uložte id každé relace a před odesláním zákazníka přečtěte action.kind; neodvozujte dostupnost odkazu ze status relace.
  • action.kind: "available" obsahuje action.url a action.expiresAt (aktuálně vždy null). Uložte action.url, odešlete na něj zákazníka a poté úkol znovu načtěte. Pole url a expiresAt na úrovni relace obsahují stejné hodnoty.
  • action.kind: "unavailable" znamená, že se nemá zobrazit žádný odkaz. Pole url a expiresAt na úrovni relace chybí. Samotný status relace neurčuje, který druh akce obdržíte.
Jde o akce v rozsahu úkolu, nikoli o samostatný životní cyklus ověření zákazníka.

Nahrání dokumentů

Když požadavek vyžaduje dokument, nahrajte jej pomocí POST /v3/customers/{customerId}/documents:
Uložte vrácené data.id jako DOCUMENT_ID předtím, než odešlete odpověď, která na něj odkazuje.

API odpovědi

Odešlete jednu kompletní sadu odpovědí pro aktuální revizi pomocí POST /v3/customers/{customerId}/tasks/{taskId}/submissions:
Každé ID požadavku a typ odpovědi vezměte z nejnovějšího úkolu. Pokud API oznámí, že se úkol změnil, znovu jej načtěte a rebuildujte odeslání z nové revize.

Předpoklad skutečného majitele pro firmy

Žádost o firemní capability, která potřebuje důkazy o skutečném majiteli, uspěje i tehdy, když zákazník zatím nemá žádného kvalifikujícího se vlastníka. Capability se vytvoří jako restricted s statusReason.code: tasks_due a firemní vstupní úkol si vyžádá chybějící fakta o vlastnictví, včetně vlastnické struktury. Tentýž úkol nese požadavek resource_reference, jehož žádost obsahuje qualification: "beneficial_owner":
Související strana se kvalifikuje, když je aktivní stranou typu person téhož zákazníka s ownership.declared: true nebo s poskytnutým procentem vlastnictví alespoň 25. Požadavek je odvozen z aktuálního seznamu souvisejících stran, takže na něj obvykle neodpovídáte přímo:
  • Vytvoření nebo aktualizace kvalifikující se související strany splní požadavek ve stejném přehodnocení a otevře vlastní profilovou a dokumentovou práci tohoto vlastníka. Viz Přidejte propojené strany firmy.
  • Na kvalifikující se stranu můžete také explicitně odkázat odpovědí resource_reference, která nese její relatedPartyId.
  • Požadavek zůstává uveden v aktuálním úkolu i po svém splnění. Když nezůstává otevřená žádná jiná povinnost, úkol se stane satisfied.
  • Archivace poslední kvalifikující se strany, nebo odstranění faktů, které ji kvalifikovaly, požadavek znovu otevře, a to i poté, co byl úkol satisfied.

Pokračujte, když je capability připravena

Přečtěte capability znovu pomocí GET /v3/customers/{customerId}/capabilities/{capabilityId}:
Nahraďte uložený stav a ID úkolů nejnovější odpovědí. Pokračujte jen tehdy, když aktuální stav capability umožňuje účet, quote nebo převod, který zamýšlíte vytvořit. Dále vyberte odpovídající cestu v Běžných tocích.