Kunder

Opprett kunden før du bygger en pay-in, payout eller utstedt bankkonto. Capabilities, kontoer og overføringer er avgrenset til denne kunden. Bruk externalId som stabil kobling til den tilhørende oppføringen i ditt system.

Environment variables

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

Individkunder

En individkunde krever kun type. Inkluder profilfelter du allerede kjenner, og legg til flere kun når gjeldende capability eller oppgave trenger dem. Opprett kunden med POST /v3/customers:

Create individual customer

curl --request POST \
  "${API_BASE}/v3/customers" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: customer-user-123" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "type": "individual",
  "externalId": "user_123",
  "individual": {
    "firstName": "Amina",
    "lastName": "Diallo",
    "residenceCountry": "FR"
  }
}
JSON

Lagre den returnerte data.id som CUSTOMER_ID. Se Individonboarding for policykontekst.

Virksomhetskunder

En virksomhet krever business.legalName. Opprett virksomheten med samme operasjon:

Create business customer

curl --request POST \
  "${API_BASE}/v3/customers" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: customer-company-456" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "type": "business",
  "externalId": "company_456",
  "business": {
    "legalName": "Acme Payments SAS"
  }
}
JSON

Lagre den returnerte data.id som CUSTOMER_ID. Se Virksomhetsonboarding for policy- og dokumentkontekst. Legg til styremedlemmer, eiere og andre deltakere i virksomheten når de er kjent eller etterspurt. Dette eksempelet oppretter et styremedlem med POST /v3/customers/{customerId}/related-parties:

Add related party

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/related-parties" \
  --header "X-API-Key: ${SWIPELUX_API_KEY}" \
  --header "Idempotency-Key: related-party-director-001" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "partyType": "person",
  "roles": ["director"],
  "title": "Chief executive officer",
  "person": {
    "firstName": "Amina",
    "lastName": "Diallo",
    "residenceCountry": "FR"
  }
}
JSON

Lagre den returnerte data.id som RELATED_PARTY_ID. Hvis du må eksportere en kunde, bruker du POST /v3/customers/{customerId}/export og følger request-skjemaet. Formatet json_basic_data returnerer gjeldende offentlige v3-kunderessurs som et JSON-vedlegg; hvert kall beregner gjeldende data på nytt og utelater dokumenter og dokumentmetadata. For et portabilitets-token-format sender du klient-ID-en til det mottakende KYC-prosjektet som forClientId, ikke Swipelux customerId. Bruk den returnerte data.token før data.expiresAt. Gjenbruk av samme Idempotency-Key og body spiller av det token-resultatet på nytt; bruk en ny nøkkel for å utstede et nytt token.

Les klarhet fra capabilities

En kunde har ikke en verifiserings- eller klarhetsstatus i API-et. Les kunden med GET /v3/customers/{customerId} for gjeldende profildata, og bruk deretter capabilities og deres openTaskIds for å avgjøre hva kunden kan gjøre videre.

Get customer

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

Finn kunder med utestående dokumenter

For å finne ut hvilke kunder på en side som fortsatt mangler obligatoriske dokumenter, sender du include=documentRequirements til GET /v3/customers. Du kan kombinere det med capability-sammendrag som include=capabilities,documentRequirements. API-nøkler trenger accounts:read for documentRequirements-utvidelsen. Hvert kundesammendrag inneholder da et documentRequirements-objekt:

Document requirement summary

{
  "documentRequirements": {
    "required": true,
    "count": 2
  }
}

count er antallet obligatoriske dokumentkrav i action_required på oppgaver som også er i action_required. Det dekker alle oppgaveomfang, inkludert kontoomfattende oppgaver, og avhenger ikke av capability-klarhet.
required er true når count er større enn 0.
Et sett med alternativer telles én gang, og bare når hvert alternativ krever et dokument.

Sammendraget er konservativt. Det utelater valgfrie dokumenter, betinget obligatoriske dokumenter og alternativer som blander dokument- og ikke-dokumentruter. Det utelater også krav kunden kan fullføre gjennom hostet verifisering. Derfor beviser ikke required: false at ingen dokumentoppgave gjelder. Bruk det til å prioritere kunder, og les deretter oppgavene deres for den autoritative listen over hva som skal samles inn. Uten utvidelsen utelater svaret documentRequirements. Deretter, fortsett til Capabilities og oppgaver for å oppdage og aktivere produktutfallet du trenger.

Kom i gang

Kundeombording

Bygg pengestrømmer

Lansering

Individkunder

Virksomhetskunder

Les klarhet fra capabilities

Finn kunder med utestående dokumenter

​Individkunder

​Virksomhetskunder

​Legg til nærstående parter for virksomheten

​Les klarhet fra capabilities

​Finn kunder med utestående dokumenter

Individkunder

Virksomhetskunder

Legg til nærstående parter for virksomheten

Les klarhet fra capabilities

Finn kunder med utestående dokumenter