Tests en sandbox

Le sandbox utilise le même hôte API que la production. Une clé API sandbox sélectionne l’environnement de test, où les assistants simulent des résultats sans déplacer de fonds réels. Conservez la clé sur votre backend. Les assistants sandbox ne remplacent pas la conformité ou l’onboarding en production. Utilisez Erreurs et nouvelles tentatives pour tester la façon dont votre intégration gère les échecs de validation, d’état et de plateforme réessayables renvoyés par les opérations sandbox.

Environment variables

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

Tester la disponibilité d’une capacité

Dans la sandbox, les capacités ACH, Wire et SWIFT, nommées comme mutualisées, sont servies uniquement chez JPMorgan Chase (jpmorgan). Omettez institutions lorsque vous demandez l’une de ces capacités et Swipelux sélectionne jpmorgan. Indiquer toute autre banque renvoie 422 capability_institutions_unsupported. La liste des capacités prises en charge dans la sandbox n’affiche que jpmorgan pour ces méthodes. Le routage en production et les autres méthodes, comme RTP, Pix et SPEI, restent inchangés.

Request a sandbox bank capability

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

Après avoir demandé une capacité, définissez son statut sandbox avec POST /v3/sandbox/customers/{customerId}/capabilities/{capabilityId}/status :

Set capability status

curl --request POST \
  "${API_BASE}/v3/sandbox/customers/${CUSTOMER_ID}/capabilities/${CAPABILITY_ID}/status" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"status":"ready"}'

Récupérez à nouveau la capacité après avoir utilisé l’assistant. Traitez son status et ses openTaskIds actuels comme le résultat que votre produit doit gérer. Une réponse 200 peut tout de même afficher du travail en cours, comme des tâches client ou une revue pending. L’outil renvoie 409 capability_status_blocked lorsque la capacité ne peut pas atteindre le statut demandé pour une raison que vous ne pouvez pas lever dans la sandbox, comme approval_scope_review_required, un blocage opérationnel ou un statut terminal. Le champ statusReason du problème contient le code et le message de la raison de la capacité, avec retryable: false. Lisez la capacité pour obtenir la resolution de la raison. Forcer une capacité nommée à rejected une deuxième fois renvoie la même capacité inchangée. Forcer une capacité rejetée à restricted ou ready renvoie 422 invalid_capability. Créez plutôt un nouveau client sandbox pour tester ces statuts.

Tester une tâche ouverte

Créez une tâche sandbox avec POST /v3/sandbox/tasks. Rattachez-la à la ressource dont vous testez le workflow et utilisez items pour décrire ce que le client doit soumettre. Ce guide présente les workflows de capacité et de transfert ; la Référence API définit le scope client et le schéma complet de la requête. Utilisez un élément explanation pour une réponse texte et un élément document pour un téléversement. Les nouveaux éléments profile exigent aussi profilePointer, un pointeur JSON qui désigne le champ client. Consultez Créer une tâche sandbox pour les autres types d’éléments et champs. Pour l’exemple de transfert, créez d’abord un transfert sandbox via un flux d’encaissement ou de paiement, puis exportez son data.id :

Transfer ID

export TRANSFER_ID='tr_replace_with_your_transfer_id'

Capacité + explication
RFI de transfert + document

curl --request POST \
  "${API_BASE}/v3/sandbox/tasks" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data @- <<JSON
{
  "scope": {
    "type": "capability",
    "customerId": "${CUSTOMER_ID}",
    "capabilityId": "${CAPABILITY_ID}"
  },
  "items": [
    {
      "type": "explanation",
      "request": "Explain the source of funds."
    }
  ]
}
JSON

Cadrez la tâche sur le transfert en cours d’examen et demandez un document avec des constraints qui restreignent les types, formats et l’ancienneté acceptés.

Create document task

curl --request POST \
  "${API_BASE}/v3/sandbox/tasks" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data @- <<JSON
{
  "scope": {
    "type": "transfer",
    "customerId": "${CUSTOMER_ID}",
    "transferId": "${TRANSFER_ID}"
  },
  "category": "transaction_rfi",
  "items": [
    {
      "type": "document",
      "request": "Upload a bank statement showing the source of funds for this transfer.",
      "constraints": {
        "acceptedDocumentTypes": ["bank_statement"],
        "acceptedFormats": ["pdf", "jpeg"],
        "maxAgeDays": 90
      }
    }
  ]
}
JSON

L’exemple limite le type, le format et l’ancienneté du document accepté. Consultez Créer une tâche sandbox pour toutes les contraintes de document prises en charge.

Stockez data.id en tant que TASK_ID, data.revision en tant que TASK_REVISION, et le data.requirements[0].id actuel en tant que REQUIREMENT_ID. Lorsque vous appelez POST /v3/customers/{customerId}/tasks/{taskId}/submissions, faites correspondre la réponse à l’élément créé :

Réponse d'explication
Réponse de document

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/tasks/${TASK_ID}/submissions" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Idempotency-Key: sandbox-task-submission-001" \
  --header "Content-Type: application/json" \
  --data @- <<JSON
{
  "taskRevision": ${TASK_REVISION},
  "answers": [
    {
      "requirementId": "${REQUIREMENT_ID}",
      "answer": {
        "type": "text",
        "value": "Sandbox requirement completed."
      }
    }
  ]
}
JSON

Téléversez un fichier correspondant avec POST /v3/customers/{customerId}/documents, stockez le data.id renvoyé en tant que DOCUMENT_ID, puis soumettez-le comme réponse de document :

Upload document

curl --request POST \
  "${API_BASE}/v3/customers/${CUSTOMER_ID}/tasks/${TASK_ID}/submissions" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Idempotency-Key: sandbox-task-document-submission-001" \
  --header "Content-Type: application/json" \
  --data @- <<JSON
{
  "taskRevision": ${TASK_REVISION},
  "answers": [
    {
      "requirementId": "${REQUIREMENT_ID}",
      "answer": {
        "type": "document",
        "documentIds": ["${DOCUMENT_ID}"]
      }
    }
  ]
}
JSON

Puis acceptez ou rejetez la soumission actuelle avec POST /v3/sandbox/tasks/{taskId}/review :

Review submission

curl --request POST \
  "${API_BASE}/v3/sandbox/tasks/${TASK_ID}/review" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"outcome":"accepted"}'

Vous pouvez examiner les tâches créées par POST /v3/sandbox/tasks et les tâches de collecte de capacités que Swipelux recueille. Examiner une tâche détenue par les Opérations ou par un autre workflow renvoie 409 task_not_sandbox_reviewable. Cette tâche reste lisible via les endpoints de tâches et attend que son propriétaire l’examine. 404 task_not_found signifie que l’ID de tâche est inconnu ou appartient à un autre marchand. Utilisez Capacités et tâches pour le modèle de complétion de tâche en production.

Alimenter un portefeuille sandbox

Créditez un portefeuille émis avec POST /v3/sandbox/accounts/{accountId}/topup :

Top up issued wallet

curl --request POST \
  "${API_BASE}/v3/sandbox/accounts/${ACCOUNT_ID}/topup" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"amount":"250.00","currency":"USDC"}'

Stockez le data.id renvoyé en tant que TRANSFER_ID lorsque vous souhaitez inspecter le transfert de financement simulé. L’id de topup est un id de transfert. Récupérez-le via GET /v3/transfers/{transferId} ou listez-le via GET /v3/transfers pour tester votre chemin de code de dépôt entrant contre les topups sandbox. La projection du transfert est un dépôt entrant en stablecoin terminé avec origin: "inbound_deposit", method: "stablecoin_transfers" et direction: "stablecoin_move", et elle est renvoyée par les filtres de liste correspondants accountId, origin, method et direction.

Terminer ou échouer un transfert

Définissez le résultat avec POST /v3/sandbox/transfers/{transferId}/state :

Terminer
Échouer

curl --request POST \
  "${API_BASE}/v3/sandbox/transfers/${TRANSFER_ID}/state" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data '{"state":"completed"}'

curl --request POST \
  "${API_BASE}/v3/sandbox/transfers/${TRANSFER_ID}/state" \
  --header "X-API-Key: ${SWIPELUX_SANDBOX_API_KEY}" \
  --header "Content-Type: application/json" \
  --data @- <<'JSON'
{
  "state": "failed",
  "stateDetail": {
    "code": "sandbox_review",
    "message": "Sandbox transfer failed."
  }
}
JSON

Ensuite, exécutez un flux d’encaissement, de paiement ou de compte bancaire émis en sandbox.

Commencer

Intégrer les clients

Construire les flux monétaires

Mise en production

Tester la disponibilité d’une capacité

Tester une tâche ouverte

Alimenter un portefeuille sandbox

Terminer ou échouer un transfert

​Tester la disponibilité d’une capacité

​Tester une tâche ouverte

​Alimenter un portefeuille sandbox

​Terminer ou échouer un transfert

Tester la disponibilité d’une capacité

Tester une tâche ouverte

Alimenter un portefeuille sandbox

Terminer ou échouer un transfert