Zákazníci

Zákazníka vytvořte předtím, než sestavíte příchozí platbu, výplatu nebo vydaný bankovní účet. Capabilities, účty a převody jsou vymezeny na daného zákazníka. Použijte externalId jako stabilní mapování na odpovídající záznam ve vašem systému.

Environment variables

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

Fyzické osoby

Fyzická osoba vyžaduje pouze type. Zahrňte profilová pole, která již znáte, a přidejte další jen tehdy, když je aktuální capability nebo úkol vyžaduje. Vytvořte zákazníka pomocí 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

Uložte vrácené data.id jako CUSTOMER_ID. Kontext politiky viz Onboarding fyzických osob.

Firemní zákazníci

Firma vyžaduje business.legalName. Vytvořte firmu stejnou operací:

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

Uložte vrácené data.id jako CUSTOMER_ID. Kontext politiky a dokumentů viz Onboarding firem. Přidejte ředitele, vlastníky a další firemní účastníky, když jsou známi nebo vyžadováni. Tento příklad vytvoří ředitele pomocí 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

Uložte vrácené data.id jako RELATED_PARTY_ID. Pokud potřebujete exportovat zákazníka, použijte POST /v3/customers/{customerId}/export a postupujte podle jeho schématu požadavku. Formát json_basic_data vrací aktuální veřejný v3 zdroj zákazníka jako přílohu JSON; každé volání znovu vypočítá aktuální data a vylučuje dokumenty i metadata dokumentů. Pro formát tokenu přenositelnosti odešlete client ID přijímajícího KYC projektu jako forClientId, nikoli Swipelux customerId. Vrácený data.token použijte před data.expiresAt. Opětovné použití stejného Idempotency-Key a těla přehraje výsledek daného tokenu; pro vydání dalšího tokenu použijte nový klíč.

Čtěte připravenost z capabilities

Zákazník nemá v API stav ověření ani připravenosti. Přečtěte zákazníka pomocí GET /v3/customers/{customerId} pro aktuální data profilu, poté použijte capabilities a jejich openTaskIds k rozhodnutí, co může zákazník dělat dále.

Get customer

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

Vyhledání zákazníků s chybějícími dokumenty

Chcete-li zjistit, kteří zákazníci na stránce ještě dluží povinné dokumenty, předejte include=documentRequirements do GET /v3/customers. Můžete to zkombinovat se souhrny capabilities jako include=capabilities,documentRequirements. API klíče potřebují pro rozšíření documentRequirements oprávnění accounts:read. Každý souhrn zákazníka pak obsahuje objekt documentRequirements:

Document requirement summary

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

count je počet povinných požadavků na dokumenty ve stavu action_required u úkolů, které jsou rovněž ve stavu action_required. Pokrývá všechny rozsahy úkolů, včetně úkolů pro celý účet, a nezávisí na připravenosti capabilities.
required je true, když je count větší než 0.
Sada alternativ se počítá jednou, a to pouze tehdy, když každá alternativa vyžaduje dokument.

Souhrn je konzervativní. Vylučuje volitelné dokumenty, podmíněně povinné dokumenty a alternativy, které kombinují cesty s dokumentem a bez dokumentu. Vylučuje také požadavky, které zákazník může splnit prostřednictvím hostovaného ověření. Hodnota required: false proto nedokazuje, že se neuplatňuje žádný úkol s dokumenty. Použijte ji k určení priorit zákazníků a poté si přečtěte jejich úkoly, kde najdete závazný seznam toho, co je třeba shromáždit. Bez rozšíření odpověď documentRequirements neobsahuje. Dále pokračujte na Capabilities a úkoly, kde objevíte a aktivujete potřebný produktový výsledek.

Začínáme

Onboarding zákazníků

Vytvořte peněžní toky

Spuštění

Fyzické osoby

Firemní zákazníci

Čtěte připravenost z capabilities

Vyhledání zákazníků s chybějícími dokumenty

​Fyzické osoby

​Firemní zákazníci

​Přidejte propojené strany firmy

​Čtěte připravenost z capabilities

​Vyhledání zákazníků s chybějícími dokumenty

Fyzické osoby

Firemní zákazníci

Přidejte propojené strany firmy

Čtěte připravenost z capabilities

Vyhledání zákazníků s chybějícími dokumenty