Capabilities og oppgaver

En capability forteller deg om en kunde kan bruke et bestemt utfall, betalingsmetode og retning. Åpne oppgaver forteller deg hva som må skje før capability-en eller en relatert ressurs kan gå videre.

export API_BASE='https://platform.swipelux.com'
export SWIPELUX_API_KEY='replace-with-your-api-key'

Oppdag støttede capabilities

Les kundens gjeldende valg med GET /v3/customers/{customerId}/capabilities/supported:

curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/capabilities/supported" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"

Velg en responsoppføring som samsvarer med tiltenkt directions, method og accountType. Fortsett kun når availability er available eller beta og eligibility.eligible er true. Hvis institutions returneres, velg kun én ID fra den responsen. Lagre den valgte data[].id som CAPABILITY_ID. Kopier aldri en capability-ID fra en annen kunde eller et annet miljø.

Pooled vs named kontotyper

Bankcapabilities finnes i to varianter, kodet som accountType-feltet og suffiks i capability-ID-en (for eksempel ach_pooled, wire_named):

pooled: delt Swipelux-bankkonto. Hver pay-in bruker en unik referanse for å rute midler. Velg denne for engangsoverføringer.
named: dedikerte bankopplysninger for kunden (virtuell IBAN, dedikert ACH-konto). Gjenbrukbare og delbare med hvilken som helst betaler. Kreves for utstedte bankkontoer.

Bruk pooled som standard. Bruk named kun når kunden trenger gjenbrukbare bankopplysninger. Sjekk supported-responsen for hvilke varianter som er tilgjengelige.

Be om capability-en

Be om det valgte alternativet med POST /v3/customers/{customerId}/capabilities/{capabilityId}:

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/capabilities/${CAPABILITY_ID}" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: capability-request-001" \
  --header "Content-Type: application/json" \
  --data '{}'

Bruk en eksplisitt institutions-liste kun når du må velge fra ID-er returnert av responsen for støttede capabilities. Lagre data.status som CAPABILITY_STATUS, data.openTaskIds som OPEN_TASK_IDS, og hver data.applications[].id i APPLICATION_IDS.

Fullfør gjeldende oppgaver

List oppgaver med GET /v3/customers/{customerId}/tasks, velg ID-er fra OPEN_TASK_IDS, og les så hver gjeldende oppgave med GET /v3/customers/{customerId}/tasks/{taskId}:

curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/tasks/${TASK_ID}" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"

Bruk siste data.revision og data.requirements. Hent oppgaven på nytt umiddelbart før innsending hvis noen av delene kan ha endret seg. Hver åpen oppgave inneholder et dueAt-tidsstempel. Når Swipelux oppretter en oppgave uten en eksplisitt forfallsdato, settes dueAt som standard til nøyaktig 31 dager etter oppgavens createdAt. Behandle dueAt som informativt: du kan ikke sette det via API-et, og det utløser ingen automatisk livssyklusovergang. Bare det separate feltet deadline forårsaker en automatisk overgang når det er satt.

Hostede handlinger

I svaret med oppgavedetaljer inneholder hver oppføring i verificationSessions og tosSessions et action-objekt. Svar med oppgavelister inneholder ikke disse handlingslenkene. Lagre id for hver sesjon, og les deretter action.kind før du sender kunden videre. Ikke utled tilgjengeligheten av lenken fra sesjonens status.

action.kind: "available" inkluderer action.url og action.expiresAt (for øyeblikket alltid null). Lagre action.url, send kunden dit, og les deretter oppgaven på nytt. Feltene url og expiresAt på sesjonsnivå inneholder de samme verdiene.
action.kind: "unavailable" betyr at ingen lenke skal vises. Feltene url og expiresAt på sesjonsnivå er fraværende. Sesjonens status alene avgjør ikke hvilken handlingstype du mottar.

{
  "data": {
    "verificationSessions": [
      {
        "id": "vfy_000000000000000003",
        "key": "identity_verification",
        "type": "identity_verification",
        "status": "action_required",
        "action": {
          "kind": "available",
          "url": "https://platform.swipelux.com/kyc/redirect/cus_000000000000000001/tsk_000000000000000002/vfy_000000000000000003",
          "expiresAt": null
        },
        "url": "https://platform.swipelux.com/kyc/redirect/cus_000000000000000001/tsk_000000000000000002/vfy_000000000000000003",
        "expiresAt": null
      }
    ],
    "tosSessions": [
      {
        "id": "vfy_000000000000000004",
        "key": "terms_of_service",
        "type": "terms_of_service",
        "status": "completed",
        "action": { "kind": "unavailable" }
      }
    ]
  }
}

Dette er oppgaveavgrensede handlinger, ikke en separat livssyklus for kundeverifisering.

Last opp dokumenter

Når et krav ber om et dokument, last det opp med POST /v3/customers/{customerId}/documents:

export DOCUMENT_PATH='/absolute/path/to/requested-document.pdf'

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/documents" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: customer-document-001" \
  --form "file=@${DOCUMENT_PATH}"

Lagre den returnerte data.id som DOCUMENT_ID før du sender inn svaret som refererer til den.

API-svar

Send inn ett komplett svarsett for gjeldende revisjon med POST /v3/customers/{customerId}/tasks/{taskId}/submissions:

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/tasks/${TASK_ID}/submissions" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: task-submission-001" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "taskRevision": 3,
  "answers": [
    {
      "requirementId": "req_from_current_task",
      "answer": {
        "type": "text",
        "value": "Current answer"
      }
    }
  ]
}
JSON

Hent hver krav-ID og svar-type fra siste oppgave. Hvis API-et melder at oppgaven har endret seg, hent den på nytt og bygg innsendingen på nytt fra den nye revisjonen.

UBO-forutsetning for virksomheter

Å be om en virksomhets-capability som trenger UBO-bevis lykkes selv når kunden ennå ikke har en kvalifiserende eier. Capability-en opprettes som restricted med statusReason.code: tasks_due, og intake-oppgaven for virksomheten ber om de manglende eierskapsfaktaene, inkludert eierskapsstrukturen. Den samme oppgaven inneholder et resource_reference-krav der forespørselen inkluderer qualification: "beneficial_owner":

{
  "type": "resource_reference",
  "prompt": "Add or select a qualifying beneficial owner.",
  "required": true,
  "resourceType": "related_party",
  "qualification": "beneficial_owner"
}

En nærstående part kvalifiserer når den er en aktiv person-part hos samme kunde med ownership.declared: true eller en oppgitt eierandel på minst 25. Kravet utledes fra den gjeldende listen over nærstående parter, så du svarer vanligvis ikke på det direkte:

Å opprette eller oppdatere en kvalifiserende nærstående part oppfyller kravet i samme reevaluering og åpner den eierens eget profil- og dokumentarbeid. Se Legg til nærstående parter for virksomheten.
Du kan også referere til en kvalifiserende part eksplisitt med et resource_reference-svar som inneholder dens relatedPartyId.
Kravet forblir oppført i den gjeldende oppgaven etter at det er oppfylt. Når ingen annen forpliktelse gjenstår som åpen, blir oppgaven satisfied.
Å arkivere den siste kvalifiserende parten, eller fjerne faktaene som kvalifiserte den, gjenåpner kravet, selv etter at oppgaven var satisfied.

Fortsett når capability-en er klar

Les capability-en på nytt med GET /v3/customers/{customerId}/capabilities/{capabilityId}:

curl --request GET \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/capabilities/${CAPABILITY_ID}" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}"

Erstatt den lagrede statusen og oppgave-ID-ene med siste respons. Fortsett kun når gjeldende capability-status tillater kontoen, tilbudet eller overføringen du har til hensikt å opprette. Deretter, velg den samsvarende reisen i Vanlige flyter.

Kom i gang

Kundeombording

Bygg pengestrømmer

Lansering

Capabilities og oppgaver

Oppdag støttede capabilities

Pooled vs named kontotyper

Be om capability-en

Fullfør gjeldende oppgaver

Hostede handlinger

Last opp dokumenter

API-svar

UBO-forutsetning for virksomheter

Fortsett når capability-en er klar

​Oppdag støttede capabilities

​Pooled vs named kontotyper

​Be om capability-en

​Fullfør gjeldende oppgaver

​Hostede handlinger

​Last opp dokumenter

​API-svar

​UBO-forutsetning for virksomheter

​Fortsett når capability-en er klar

Oppdag støttede capabilities

Pooled vs named kontotyper

Be om capability-en

Fullfør gjeldende oppgaver

Hostede handlinger

Last opp dokumenter

API-svar

UBO-forutsetning for virksomheter

Fortsett når capability-en er klar