Sandbox-Tests

Die Sandbox verwendet denselben API-Host wie die Produktion. Ein Sandbox-API-Schlüssel wählt die Testumgebung aus, in der Hilfsfunktionen Ergebnisse simulieren, ohne echte Gelder zu bewegen. Bewahren Sie den Schlüssel auf Ihrem Backend auf. Sandbox-Hilfsfunktionen ersetzen nicht die produktive Compliance oder das Onboarding. Verwenden Sie Fehler und Wiederholungen, um zu testen, wie Ihre Integration Validierungs-, Zustands- und wiederholbare Plattformfehler behandelt, die von Sandbox-Operationen zurückgegeben werden.

Environment variables

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

Fähigkeitsbereitschaft testen

In der Sandbox werden ACH-, Wire- und SWIFT-Fähigkeiten, sowohl benannte als auch gepoolte, ausschließlich bei JPMorgan Chase (jpmorgan) bereitgestellt. Lassen Sie institutions weg, wenn Sie eine dieser Fähigkeiten anfordern, und Swipelux wählt jpmorgan. Die Angabe einer anderen Bank gibt 422 capability_institutions_unsupported zurück. Die Liste der unterstützten Fähigkeiten zeigt in der Sandbox für diese Methoden nur jpmorgan. Das Produktions-Routing und andere Methoden wie RTP, Pix und SPEI bleiben unverändert.

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"]}'

Setzen Sie nach der Anforderung einer Fähigkeit deren Sandbox-Status mit 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"}'

Rufen Sie die Fähigkeit nach dem Einsatz der Hilfsfunktion erneut ab. Behandeln Sie deren aktuellen status und openTaskIds als das Ergebnis, das Ihr Produkt verarbeiten muss. Eine 200-Antwort kann trotzdem offene Arbeit zeigen, etwa Kundenaufgaben oder eine pending-Prüfung. Die Hilfsfunktion gibt 409 capability_status_blocked zurück, wenn die Fähigkeit den angeforderten Status aus einem Grund nicht erreichen kann, den Sie in der Sandbox nicht beheben können, etwa approval_scope_review_required, eine betriebliche Sperre oder einen Endstatus. Das Feld statusReason des Problems enthält den Grundcode und die Nachricht der Fähigkeit mit retryable: false. Lesen Sie die Fähigkeit, um die resolution des Grundes zu erhalten. Wenn Sie eine benannte Fähigkeit ein zweites Mal auf rejected erzwingen, wird dieselbe Fähigkeit unverändert zurückgegeben. Wenn Sie eine abgelehnte Fähigkeit auf restricted oder ready erzwingen, wird 422 invalid_capability zurückgegeben. Erstellen Sie stattdessen einen neuen Sandbox-Kunden, um diese Status zu testen.

Eine offene Aufgabe testen

Erstellen Sie eine Sandbox-Aufgabe mit POST /v3/sandbox/tasks. Ordnen Sie sie der Ressource zu, deren Workflow Sie testen, und beschreiben Sie mit items, was der Kunde einreichen muss. Dieser Leitfaden zeigt Capability- und Transfer-Workflows; die API-Referenz definiert den Kunden-Scope und das vollständige Request-Schema. Verwenden Sie ein explanation-Element für eine Textantwort und ein document-Element für einen Upload. Neue profile-Elemente erfordern außerdem profilePointer, einen JSON Pointer auf das Kundenfeld. Weitere Elementtypen und Felder finden Sie unter Sandbox-Aufgabe erstellen. Erstellen Sie für das Transfer-Beispiel zunächst einen Sandbox-Transfer über einen Pay-in- oder Payout-Ablauf und exportieren Sie anschließend die zurückgegebene data.id:

Transfer ID

export TRANSFER_ID='tr_replace_with_your_transfer_id'

Fähigkeit + Erklärung
Transfer-RFI + Dokument

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

Ordnen Sie die Aufgabe dem zu prüfenden Transfer zu und fordern Sie ein Dokument mit constraints an, die die akzeptierten Typen, Formate und das Alter einschränken.

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

Das Beispiel begrenzt den akzeptierten Dokumenttyp, das Format und das Alter. Alle unterstützten Dokumenteinschränkungen finden Sie unter Sandbox-Aufgabe erstellen.

Speichern Sie data.id als TASK_ID, data.revision als TASK_REVISION und die aktuelle data.requirements[0].id als REQUIREMENT_ID. Stimmen Sie beim Aufruf von POST /v3/customers/{customerId}/tasks/{taskId}/submissions die Antwort auf das erstellte Element ab:

Erklärungsantwort
Dokumentantwort

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

Laden Sie mit POST /v3/customers/{customerId}/documents eine passende Datei hoch, speichern Sie die zurückgegebene data.id als DOCUMENT_ID und senden Sie sie als Dokumentantwort:

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

Akzeptieren oder lehnen Sie die aktuelle Einreichung dann mit POST /v3/sandbox/tasks/{taskId}/review ab:

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"}'

Sie können Aufgaben prüfen, die mit POST /v3/sandbox/tasks erstellt wurden, sowie die Aufnahmeaufgaben für Fähigkeiten, die Swipelux erfasst. Das Prüfen einer Aufgabe, die Operations oder einem anderen Workflow gehört, gibt 409 task_not_sandbox_reviewable zurück. Diese Aufgabe bleibt über die Aufgaben-Endpunkte lesbar und wartet auf die Prüfung durch ihren Eigentümer. 404 task_not_found bedeutet, dass die Aufgaben-ID unbekannt ist oder zu einem anderen Händler gehört. Verwenden Sie Fähigkeiten und Aufgaben für das produktive Muster zur Aufgabenerfüllung.

Eine Sandbox-Wallet finanzieren

Belasten Sie eine ausgegebene Wallet mit 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"}'

Speichern Sie das zurückgegebene data.id als TRANSFER_ID, wenn Sie den simulierten Finanzierungstransfer prüfen möchten. Die Topup-ID ist eine Transfer-ID. Rufen Sie sie über GET /v3/transfers/{transferId} ab oder listen Sie sie über GET /v3/transfers auf, um Ihren Code-Pfad für eingehende Einzahlungen gegen Sandbox-Topups zu testen. Die Transferprojektion ist eine abgeschlossene eingehende Stablecoin-Einzahlung mit origin: "inbound_deposit", method: "stablecoin_transfers" und direction: "stablecoin_move" und wird von den passenden Listenfiltern accountId, origin, method und direction zurückgegeben.

Einen Transfer abschließen oder fehlschlagen lassen

Setzen Sie das Ergebnis mit POST /v3/sandbox/transfers/{transferId}/state:

Abschließen
Fehlschlagen

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

Führen Sie als Nächstes einen Pay-in-, Payout- oder Ausgegebenes-Bankkonto-Flow in der Sandbox aus.

Erste Schritte

Kunden onboarden

Geldflüsse aufbauen

Livegang

Fähigkeitsbereitschaft testen

Eine offene Aufgabe testen

Eine Sandbox-Wallet finanzieren

Einen Transfer abschließen oder fehlschlagen lassen

​Fähigkeitsbereitschaft testen

​Eine offene Aufgabe testen

​Eine Sandbox-Wallet finanzieren

​Einen Transfer abschließen oder fehlschlagen lassen

Fähigkeitsbereitschaft testen

Eine offene Aufgabe testen

Eine Sandbox-Wallet finanzieren

Einen Transfer abschließen oder fehlschlagen lassen