Entwickler/Go-live

Sandbox

Die Sandbox ist eine eigene Testkopie von CardV. Hier bauen und testen Sie Ihre Anbindung ohne echtes Geld und ohne echte Produkte.

Siehe auch: Übersicht · Authentifizierung

LiveSandbox
API-Basis-URLhttps://b2b.cardv.net/api/v1https://sandbox.cardv.net/api/v1
Portalhttps://b2b.cardv.net/portal/Dasselbe Portal, oben auf Sandbox umschalten

#Zugang

  1. Ihr Unternehmen muss zuerst von CardV freigegeben sein.
  2. Melden Sie sich im Portal an und wählen Sie oben Sandbox. Direkt bei der Sandbox anmelden können Sie sich nicht.
  3. Beim ersten Mal legt CardV Ihr Sandbox-Konto an. Es hat dieselbe Merchant ID und 1.000 USD Testgeld.
  4. In der Sandbox erstellt ein Owner einen Sandbox-API-Key und lässt ihn anzeigen. Live-Keys funktionieren hier nicht.
  5. Optional: Richten Sie einen Sandbox-Webhook ein. Er hat ein eigenes Signatur-Secret.

#Was getrennt ist

  • Die Sandbox hat eigene Keys, eine eigene Wallet, eigene Bestellungen, Webhooks, IP-Allowlist und ein eigenes Audit-Log.
  • Einstellungen werden nicht übernommen. Richten Sie Keys, Webhooks und die IP-Allowlist in jeder Umgebung einzeln ein.
  • Sandbox-Bestellungen kaufen nie echte Produkte. Testcodes lassen sich nicht einlösen.
  • Testgeld hat keinen Wert. Sie können es in der Sandbox weder aufladen noch auszahlen oder nach Live übertragen.
  • Wenn Ihr Testgeld aufgebraucht ist, bitten Sie den CardV-Support um Nachschub.

#Testgeld

Bestellungen verbrauchen Testgeld genauso wie Live-Bestellungen echtes Geld. Fehlgeschlagene Testbestellungen werden auf dieselbe Weise erstattet. Die Buchungen mit Testgeld sehen Sie im Portal auf der Seite mit den Wallet-Buchungen.

#Testkatalog

  • Der Sandbox-Katalog ist klein und enthält nur Testprodukte.
  • Die SKU-IDs unterscheiden sich von Live. Suchen Sie sie in der Sandbox immer mit GET/skus.
  • Übernehmen Sie nie Sandbox-IDs in Ihre Live-Konfiguration und umgekehrt.
  • Preise, Verfügbarkeit und Liefergeschwindigkeit sind in der Sandbox anders als in Live.

#Test-Checkliste

  • GET/account zeigt Ihre Merchant ID und "api_access_enabled": true.
  • GET/balance funktioniert.
  • Sie können GET/skus seitenweise durchgehen und bestellen nur SKUs mit available.
  • Eine signierte Bestellung klappt. Eine falsche Signatur ergibt HTTP 403.
  • Sie senden expected_unit_price in jeder Bestellposition mit.
  • Eine Bestellung einer SKU mit Bereich und amount klappt (falls die Sandbox eine hat).
  • Dieselbe Bestellung zweimal senden (neue Nonce, gleicher Body, gleiche Bestellnummer) liefert HTTP 200 mit derselben order_id. Ihr Guthaben wird nur einmal belastet.
  • Dieselbe Bestellnummer mit anderem Body liefert HTTP 400 bei external_order_id.
  • Nach einem Timeout sendet Ihr Code dieselbe Bestellung erneut, statt eine neue Bestellnummer zu vergeben.
  • Sie lesen deliveries[].display_fields und geben sie an den Kunden weiter.
  • Sie behandeln failed, refunded und partially_succeeded.
  • Ihr Webhook-Code besteht den Testvektor und danach einen echten Sandbox-Webhook. Doppelte Nachrichten werden ignoriert.
  • Nach HTTP 429 warten Sie Retry-After ab.
  • Ihre Logs enthalten keine API-Keys, Signaturen, Codes oder Kontodaten von Kunden.

#Checkliste für den Livegang

  • Erstellen Sie im Live-Portal einen Live-API-Key. Speichern Sie ihn im Secret Store Ihrer Produktivumgebung.
  • Stellen Sie die Basis-URL in der Konfiguration auf https://b2b.cardv.net/api/v1 um.
  • Laden Sie den Live-Katalog und ordnen Sie Ihre Produkte den Live-SKU-IDs zu.
  • Laden Sie Ihre Live-Wallet im Portal auf. Richten Sie eine Warnung bei niedrigem Guthaben ein.
  • Optional: Tragen Sie Ihre Server-IPs in die Live-IP-Allowlist ein.
  • Richten Sie einen Live-Webhook ein und hinterlegen Sie sein Signatur-Secret auf Ihren Servern.
  • Klären Sie Ihre Bestelllimits und Ihr Anfragelimit mit CardV.
  • Geben Sie eine kleine Live-Bestellung auf. Prüfen Sie Abbuchung, Codes und Webhook. Steigern Sie das Volumen dann schrittweise.
  • Gleichen Sie täglich ab, mit der Buchungsseite und den Exporten im Portal.
  • Schalten Sie für alle Owner die Zwei-Faktor-Authentifizierung ein.

#Fehlerbehebung

HTTP 403 error code: 1010

Vor dem Sandbox-Host sitzt ein Netzwerk-Edge-Dienst. Manche HTTP-Clients erhalten dort HTTP 403 mit dem reinen Text error code: 1010. Die Anfrage ist gar nicht bei CardV angekommen. Ein anderer Key oder eine andere Signatur hilft deshalb nicht.

  • Setzen Sie einen aussagekräftigen User-Agent.
  • Hält das Problem an, schicken Sie dem CardV-Support Ihre Server-IP, Ihren User-Agent und die Uhrzeit.
  • Weichen Sie zum Testen nie auf Live aus.

Fragen zur Integration? Schreiben Sie an [email protected] und nennen Sie Ihre Merchant ID sowie die Bestell- oder Request-ID.