Customers

Pay-in, payout, या issued bank account बनाने से पहले customer बनाएँ। Capabilities, accounts, और transfers उस customer के scope में होते हैं। अपने system में संबंधित record की स्थिर mapping के रूप में externalId का उपयोग करें।

Environment variables

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

Individual customers

एक individual के लिए केवल type आवश्यक है। जो profile fields आप पहले से जानते हैं उन्हें शामिल करें, और अधिक तब जोड़ें जब वर्तमान capability या task को उनकी आवश्यकता हो। Customer को 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

लौटाए गए data.id को CUSTOMER_ID के रूप में संग्रहीत करें। नीति संदर्भ के लिए Individual onboarding देखें।

Business customers

एक business के लिए business.legalName आवश्यक है। उसी operation के साथ business बनाएँ:

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

लौटाए गए data.id को CUSTOMER_ID के रूप में संग्रहीत करें। नीति और document संदर्भ के लिए Business onboarding देखें। Directors, owners, और अन्य business participants को तब जोड़ें जब वे ज्ञात हों या अनुरोध किए गए हों। यह उदाहरण POST /v3/customers/{customerId}/related-parties के साथ एक director बनाता है:

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

लौटाए गए data.id को RELATED_PARTY_ID के रूप में संग्रहीत करें। यदि आपको customer export करना है, तो POST /v3/customers/{customerId}/export का उपयोग करें और उसके request schema का पालन करें। json_basic_data format वर्तमान public v3 customer resource को JSON attachment के रूप में लौटाता है; प्रत्येक call वर्तमान data की फिर से गणना करती है और documents तथा document metadata को शामिल नहीं करती। Portability-token format के लिए, Swipelux customerId नहीं बल्कि receiving KYC project की client ID को forClientId के रूप में भेजें। लौटाए गए data.token का उपयोग data.expiresAt से पहले करें। वही Idempotency-Key और body दोबारा उपयोग करने पर वही token result replay होता है; दूसरा token जारी करने के लिए नई key का उपयोग करें।

Capabilities से readiness पढ़ें

API में एक customer की verification या readiness status नहीं होती। वर्तमान profile data के लिए customer को GET /v3/customers/{customerId} के साथ पढ़ें, फिर यह तय करने के लिए कि customer आगे क्या कर सकता है, capabilities और उनके openTaskIds का उपयोग करें।

Get customer

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

बकाया documents वाले customers खोजें

यह पता लगाने के लिए कि किसी page पर कौन-से customers को अभी भी mandatory documents देने हैं, GET /v3/customers को include=documentRequirements पास करें। आप इसे capability summaries के साथ include=capabilities,documentRequirements के रूप में combine कर सकते हैं। documentRequirements expansion के लिए API keys को accounts:read की आवश्यकता होती है। इसके बाद हर customer summary में एक documentRequirements object शामिल होता है:

Document requirement summary

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

count उन mandatory document requirements की संख्या है जो action_required में हैं और ऐसे tasks पर हैं जो भी action_required में हैं। यह हर task scope को cover करता है, जिसमें account-wide tasks भी शामिल हैं, और यह capability readiness पर निर्भर नहीं करता।
जब count 0 से अधिक होता है, तब required true होता है।
Alternatives का एक set एक बार गिना जाता है, और केवल तभी जब हर alternative के लिए document आवश्यक हो।

यह summary conservative है। इसमें optional documents, conditionally required documents, और ऐसे alternatives शामिल नहीं होते जो document और non-document routes को मिलाते हैं। इसमें वे requirements भी शामिल नहीं होते जिन्हें customer hosted verification के ज़रिए पूरा कर सकता है। इसलिए required: false यह साबित नहीं करता कि कोई document task लागू नहीं होता। Customers को prioritize करने के लिए इसका उपयोग करें, फिर क्या collect करना है इसकी authoritative list के लिए उनके tasks पढ़ें। Expansion के बिना, response में documentRequirements शामिल नहीं होता। आगे, आवश्यक product outcome को खोजने और सक्रिय करने के लिए Capabilities और tasks पर जारी रखें।

शुरू करें

ग्राहकों को शामिल करें

धन प्रवाह बनाएँ

लॉन्च

Individual customers

Business customers

Capabilities से readiness पढ़ें

बकाया documents वाले customers खोजें

​Individual customers

​Business customers

​Business related parties जोड़ें

​Capabilities से readiness पढ़ें

​बकाया documents वाले customers खोजें

Individual customers

Business customers

Business related parties जोड़ें

Capabilities से readiness पढ़ें

बकाया documents वाले customers खोजें