By
·
10 minute read
In der Architektur jeder E-Commerce-Plattform ist der Checkout-Endpunkt — häufig /v1/orders oder /v1/checkout — der sogenannte „Money Endpoint": der einzige Kanal, durch den jeder Euro Umsatz fließen muss. Anders als ein GET /products-Endpunkt, bei dem ein Fehler lediglich ärgerlich ist, ist ein Fehler beim Checkout katastrophal. Er bedeutet einen verlorenen Kauf, einen frustrierten Kunden und potenziell dauerhaften Reputationsschaden. Für Frontend-Entwickler und Mobile-Engineers, die Ihre API integrieren, ist die Checkout-Dokumentation das Handbuch einer Entschärfungseinheit: Ein falscher Parameter — und der gesamte Vorgang scheitert. Dieser Leitfaden zeigt Ihnen, welche Komponenten in Standard-API-Dokumentationen fast immer fehlen, und wie Sie eine Dokumentation schreiben, die Ihre Integratoren befähigt, einen robusten, konvertierungsstarken Checkout-Flow für den deutschen Markt zu bauen — inklusive DSGVO, DSP2/3D Secure und Kauf auf Rechnung.
.svg)
🗝 Das Wichtigste — Spickzettel für Entwickler
- Die Einsätze: Dies ist der risikoreichste Endpunkt Ihrer gesamten API. Die Dokumentation muss Idempotenz (Schutz vor Doppelabbuchungen) und Sicherheit (PCI-DSS-Compliance, DSP2/3D Secure) explizit und vollständig abdecken.
- Die Struktur: Beschreiben Sie nicht nur Felder — erklären Sie Abhängigkeiten (z. B. „Wenn
payment_method=sepa_lastschrift, sindibanundbicPflichtfelder"). - Die Fehler: Ein generischer „400 Bad Request" ist beim Checkout inakzeptabel. Dokumentieren Sie granulare Fehlercodes für Bestandsfehler, Zahlungsablehnungen und Validierungsprobleme.
- Der Flow: Checkout in Deutschland ist häufig asynchron. Ihre Dokumentation muss den Unterschied zwischen
order.created(Kaufabsicht) undorder.paid(Zahlungsbestätigung) erklären — besonders für SEPA-Lastschrift und Kauf auf Rechnung. - DACH-Besonderheiten: Kauf auf Rechnung (Klarna, Afterpay), SEPA-Lastschrift und Bizum sind in Deutschland marktbeherrschend. Ihre Dokumentation muss diese Flows explizit abbilden — nicht nur Kreditkarte und PayPal.
Pre-Flight-Kontext: Authentifizierung und State-Abhängigkeiten
Bevor ein Entwickler auch nur einen Blick auf den JSON-Body wirft, muss er die Grundregeln kennen. Die Pre-Flight-Dokumentation ist der erste Abschnitt, den erfahrene Integratoren lesen — und der erste, der in schlechter Dokumentation fehlt.
State-Abhängigkeiten klar dokumentieren
Checkout passiert nie im Vakuum. Ihre Dokumentation muss folgende Fragen unmissverständlich beantworten:
Erstens: Ist eine Cart-ID erforderlich? Kann ich diesen Endpunkt mit einer rohen SKU-Liste aufrufen, oder muss ich zuvor über POST /carts einen Warenkorb anlegen? Zweitens: Welchen Token-Scope erfordert der Request? Benötigt das API-Token spezifische Scopes wie write:orders oder payments? Drittens: Sperrt der Aufruf dieses Endpunkts den Bestand temporär — und für wie lange? Diese Angaben sind nicht optional, sondern die Grundlage für korrekte Integrationsentscheidungen.
⚠ Voraussetzungen für diesen Endpunkt:
- Gültige cart_id erforderlich, generiert innerhalb der letzten 30 Minuten
- Warenkorb darf nicht leer sein (mind. 1 aktives Produkt)
- API-Token muss Scope 'write:orders' besitzen
- Bei Zahlung per SEPA-Lastschrift: SEPA-Mandat muss vorab erstellt werden
(POST /v1/mandates) — Rückgabe: mandate_id für den Checkout-Payload
Hinweis: Der Aufruf dieses Endpunkts sperrt den Bestand für 900 Sekunden
(15 Minuten). Danach wird die Reservierung automatisch freigegeben.Token-Scope und Sicherheitskontext
Für den deutschen Markt ist ein zusätzlicher Sicherheitskontext besonders relevant: DSP2 (Payment Services Directive 2) schreibt für alle Kartenzahlungen in der EU eine Starke Kundenauthentifizierung (SCA) vor. Das bedeutet, dass Ihr Checkout-Flow 3D Secure 2.0 unterstützen muss. Dokumentieren Sie explizit, welche zusätzlichen Parameter für den 3DS2-Flow übergeben werden müssen (browser_info, device_fingerprint, challenge_indicator) und wie der Redirect-Flow für die Authentifizierungsseite der Bank konfiguriert wird. Informationen zu den aktuellen DSP2-Anforderungen finden Sie direkt bei der BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht).
Der Checkout-Payload enthält personenbezogene Daten (Name, Adresse, E-Mail, ggf. IBAN). Das vollständige Logging von Checkout-Requests in Klartext-Logfiles verstößt gegen Art. 5 DSGVO (Datensparsamkeit und Speicherbegrenzung). Stellen Sie sicher, dass Ihre API-Server in der Produktivumgebung keine vollständigen Checkout-Payloads loggen. Sensible Felder wie payment_token, iban und card_last4 müssen in Logs entweder vollständig geschwärzt oder durch Pseudonyme ersetzt werden. Dies gilt auch für Webhook-Payloads und interne Event-Queues.
Der Payload-Vertrag: Validierung und Feldabhängigkeiten
Standard-Dokumentation listet Felder auf. Exzellente Dokumentation erklärt Beziehungen zwischen Feldern. Ein Checkout-Payload ist komplex: Er enthält Kunden-PII, Lieferadressen, Zahlungstoken und ggf. steuerrelevante Identifikationsnummern. Die häufigste Quelle von Integrationsproblemen ist nicht fehlendes technisches Verständnis — es ist undokumentierte Conditional Logic.
Vollständiges Payload-Beispiel für den deutschen Markt
POST /v1/checkout HTTP/1.1
Host: api.shippypro.com
Authorization: Bearer <ihr_api_token>
Content-Type: application/json
Idempotency-Key: bestellung-2026-usr-4821-ts-1706528400
X-ShippyPro-Version: 2026-01
{
"cart_id": "cart_9f3a2b1c",
"customer": {
"email": "max.mustermann@beispiel.de",
"phone": "+4917612345678", // Pflicht für DHL Express, DPD
"language": "de"
},
"shipping_address": {
"first_name": "Max",
"last_name": "Mustermann",
"street": "Musterstraße",
"house_number": "42", // Getrennt von street — DE-Standard
"city": "Berlin",
"postal_code": "10115", // PLZ: genau 5 Stellen
"country_code": "DE"
},
"billing_address": {
// Pflicht wenn payment_method = "kreditkarte" (AVS-Prüfung)
// Optional für SEPA-Lastschrift und Kauf auf Rechnung
"same_as_shipping": true
},
"payment": {
"method": "sepa_lastschrift",
"mandate_id": "mnd_7f9e3a2b", // Pflicht für SEPA — vorab via POST /mandates
"save_for_future": false
// Alternativ: "method": "kauf_auf_rechnung" — kein mandate_id erforderlich
// Alternativ: "method": "paypal" — redirect_url erforderlich
// Alternativ: "method": "kreditkarte" + "payment_token": "tok_xyz"
},
"shipping": {
"carrier": "dhl",
"service": "paket",
"preferred_delivery": { // DE-spezifisch: DHL Wunschlieferung
"type": "neighbour", // Optionen: neighbour, drop_off, packstation
"packstation_id": null
}
},
"tax": {
"vat_rate": 19, // DE: 19% Regelsteuersatz, 7% ermäßigt
"b2b": false,
"company_name": null,
"steuernummer": null // Pflicht nur für B2B-Rechnungen
},
"metadata": {
"order_source": "webshop",
"campaign_id": "summer_sale_2026"
}
}Feldabhängigkeiten für den DACH-Markt dokumentieren
Die folgende Tabelle zeigt die kritischen bedingten Pflichtfelder, die für den deutschen und DACH-Markt spezifisch sind und in Ihrer API-Dokumentation explizit ausgewiesen werden müssen:
| Feld | Typ | Bedingung | DACH-Besonderheit |
|---|---|---|---|
phone |
String (E.164) | Pflicht wenn carrier = DHL Express, DPD, Hermes | Format: +49XXXXXXXXXX — keine führende 0 |
mandate_id |
String | Pflicht wenn payment_method = sepa_lastschrift | SEPA-Mandat muss vorab per POST /mandates erstellt werden |
house_number |
String | Immer Pflicht für DE/AT/CH-Adressen | Hausnummer getrennt von Straße — DHL-Validierungsanforderung |
postal_code |
String | Immer Pflicht | PLZ: genau 5 Stellen (DE), 4 Stellen (AT/CH) |
packstation_id |
String | Pflicht wenn preferred_delivery.type = packstation | DHL Packstation-Nummer, 6-stellig |
steuernummer |
String | Pflicht wenn b2b = true und country = DE | Format: 11 Stellen (DE) — für B2B-Rechnungsstellung |
vat_id |
String | Pflicht wenn b2b = true und EU-Lieferung | Format: DE + 9 Stellen (USt-IdNr.) — für Reverse Charge |
billing_address |
Object | Pflicht wenn payment_method = kreditkarte | AVS-Prüfung (Address Verification) durch Kartenherausgeber |
Idempotenz — Das Sicherheitsnetz gegen Doppelabbuchungen
Dies ist das wichtigste technische Konzept für Zahlungs-APIs — und dennoch fehlt es in der Mehrzahl aller API-Dokumentationen vollständig. Ohne korrekt dokumentierte und implementierte Idempotenz riskieren Sie das schlimmste aller E-Commerce-Szenarien: ein Kunde wird zweimal für dieselbe Bestellung belastet.
Das Szenario: Tunnel, Timeout, Retry
Ein Nutzer im Zug klickt auf „Jetzt kaufen". Der Zug fährt in einen Tunnel. Der Request wird gesendet, aber die Antwort geht verloren. Die App wiederholt den Request automatisch. Ohne Idempotenz: Der Kunde wird zweimal abgebucht. Mit Idempotenz: Der Server erkennt den „Retry-Key" und gibt die ursprüngliche Erfolgsantwort zurück — ohne eine neue Abbuchung auszulösen.
Der Entwickler implementiert automatische Retries ohne Idempotency-Key. Bei Netzwerktimeouts — besonders häufig auf mobilen Geräten — entstehen Doppelbestellungen. Der Support-Aufwand ist enorm, das Vertrauen des Kunden dauerhaft beschädigt.
Jeder Checkout-Request trägt einen eindeutigen Idempotency-Key-Header. Retries liefern immer dieselbe ursprüngliche Antwort zurück — keine Doppelabbuchung, kein doppelter Versandauftrag, kein Support-Ticket.
Idempotenz korrekt dokumentieren
Legen Sie explizit fest, welcher Header zu verwenden ist: Idempotency-Key (Stripe-Standard) oder X-Request-ID. Definieren Sie das Format: UUID v4 oder ein zusammengesetzter Schlüssel aus User-ID + Timestamp. Beispiel: Idempotency-Key: usr-4821-cart-9f3a-ts-1706528400
Erklären Sie: Wenn ein Request mit demselben Idempotency-Key innerhalb von X Stunden/Tagen erneut gesendet wird, gibt der Server die gecachte ursprüngliche Antwort zurück — keine neue Abbuchung, keine neue Bestellanlage. Definieren Sie die Cache-Dauer (empfohlen: mindestens 24 Stunden).
Was passiert, wenn ein Idempotency-Key mit einem anderen Payload erneut verwendet wird? Dokumentieren Sie den 409 Conflict-Fall: Der Server erkennt, dass der Key bereits mit einem anderen Payload assoziiert ist, und gibt einen Fehler zurück — anstatt die neue Abbuchung auszuführen.
Asynchrone Verarbeitung: Der Pending-Zustand in Deutschland
Im modernen deutschen E-Commerce ist eine sofortige Zahlungsbestätigung die Ausnahme, nicht die Regel. Die beliebtesten Zahlungsmethoden in Deutschland — SEPA-Lastschrift, Kauf auf Rechnung (Klarna, Afterpay, Ratepay) und SEPA-Überweisung — sind von Natur aus asynchron: Die Bestellung wird angelegt, aber die Zahlungsbestätigung folgt erst Stunden oder Tage später.
Synchrone vs. asynchrone Zahlungsantworten dokumentieren
| Zahlungsmethode | HTTP-Antwort | Status | Finale Bestätigung | Verzögerung |
|---|---|---|---|---|
| Kreditkarte (3DS2) | 200 OK | paid |
Sofort in API-Response | 0–5 Sek. |
| PayPal | 200 OK | paid |
Sofort nach Redirect | 0–10 Sek. |
| Klarna Sofort | 200 OK | paid |
Sofort nach Redirect | 0–10 Sek. |
| Klarna Rechnung | 202 Accepted | pending_payment |
Webhook: payment.authorized |
Sofort bis 30 Min. |
| SEPA-Lastschrift | 202 Accepted | pending_payment |
Webhook: payment.success |
1–3 Werktage |
| Kauf auf Rechnung | 202 Accepted | pending_payment |
Webhook: payment.success |
14–30 Tage |
| SEPA-Überweisung | 202 Accepted | pending_payment |
Webhook: payment.received |
1–2 Werktage |
Für alle asynchronen Zahlungsmethoden muss Ihre Dokumentation direkt auf den Webhooks-Abschnitt verlinken und klarstellen: Die finale „Bestellung bezahlt"-Bestätigung kommt nicht in der unmittelbaren API-Antwort — sie kommt als Webhook-Event (payment.success oder payment.authorized). Entwickler, die nur auf die synchrone API-Antwort reagieren, werden für SEPA-Lastschrift und Kauf auf Rechnung niemals eine Zahlungsbestätigung erhalten. Für die Integration mit der ShippyPro KI-Versandautomatisierung empfehlen wir, den Versandauftrag erst nach Empfang des payment.success-Webhooks auszulösen — nicht bereits nach dem 202 Accepted.
Granulare Fehlerbehandlung: Der „Unhappy Path" für Deutschland
Ein generischer 400 Bad Request oder 500 Server Error beim Checkout ist für Support-Teams ein Albtraum und für Entwickler eine Sackgasse. Die Client-Applikation muss wissen, genau was dem Nutzer kommuniziert werden soll. Für den deutschen Markt sind dabei einige Fehlercodes besonders kritisch, die in internationalen Dokumentationen oft fehlen.
Checkout-spezifische Fehlercodes — Vollständige Referenz
| Fehlercode | HTTP-Status | UI-Meldung (DE) | Empfohlene Client-Aktion |
|---|---|---|---|
inv_001 |
409 | „Artikel [SKU] ist nicht mehr vorrätig." | Artikel aus Warenkorb entfernen, Nutzer informieren |
inv_002 |
409 | „Nur noch [X] Stück von [SKU] verfügbar." | Menge im Warenkorb automatisch anpassen |
pay_declined |
402 | „Zahlung vom Kreditinstitut abgelehnt." | Andere Zahlungsmethode anbieten |
pay_3ds_failed |
402 | „3D Secure Authentifizierung fehlgeschlagen." | 3DS-Flow erneut starten oder andere Karte anbieten |
pay_sepa_invalid_iban |
400 | „Die eingegebene IBAN ist ungültig." | IBAN-Feld rot markieren, Validierung client-seitig ergänzen |
pay_klarna_rejected |
402 | „Kauf auf Rechnung für diese Bestellung nicht verfügbar." | Alternative Zahlungsmethoden anzeigen, keine Begründung kommunizieren |
addr_plz_invalid |
400 | „Die Postleitzahl entspricht nicht der angegebenen Stadt." | PLZ- und Stadtfeld rot markieren |
addr_packstation_invalid |
400 | „Die angegebene Packstation-Nummer existiert nicht." | DHL-Packstations-Finder verlinken |
cart_expired |
410 | „Ihr Warenkorb ist abgelaufen. Bitte neu befüllen." | Nutzer zur Produktseite weiterleiten |
limit_exceeded |
400 | „Maximale Bestellmenge für [SKU] überschritten." | Menge automatisch auf das Maximum reduzieren |
mandate_missing |
400 | „Kein gültiges SEPA-Mandat vorhanden." | SEPA-Mandat-Erstellungsflow starten (POST /mandates) |
race_condition |
409 | „Ein anderer Checkout-Vorgang ist noch aktiv." | 2 Sekunden warten, dann erneut versuchen |
Wenn Klarna oder ein anderer Kauf-auf-Rechnung-Anbieter eine Bestellung ablehnt (pay_klarna_rejected), dürfen Sie dem Kunden keine Begründung für die Ablehnung kommunizieren — nicht einmal „zu hoher Bestellwert" oder „Adresse nicht verifiziert". Das ist eine vertragliche Anforderung aller BNPL-Anbieter und schützt gleichzeitig den Datenschutz des Kunden. Zeigen Sie nur an, dass die Zahlungsmethode für diese Bestellung nicht verfügbar ist, und bieten Sie Alternativen an.
Sandbox-Testing: Wie Entwickler den Checkout sicher testen
Sie können nicht erwarten, dass Entwickler den Checkout mit echten Kreditkarten oder echten SEPA-Mandaten testen. Ihre Dokumentation muss eine vollständige Testing-Sektion enthalten — für alle in Deutschland relevanten Zahlungsmethoden. Die offizielle Testdokumentation für PCI-konforme Sandbox-Umgebungen finden Sie beim PCI Security Standards Council.
Test-Trigger für DACH-relevante Szenarien
Unterscheiden Sie unmissverständlich zwischen Produktiv- und Sandbox-Umgebung. Empfohlenes Format in der Dokumentation: Produktiv: https://api.shippypro.com/v1/ — Sandbox: https://api.sandbox.shippypro.com/v1/. Warnen Sie explizit davor, dass Sandbox-Anfragen niemals das Lager oder Versanddienstleister erreichen.
Stellen Sie eine vollständige Liste bereit: 4242 4242 4242 4242 = Erfolgreiche Zahlung, 4000 0000 0000 0002 = Karte abgelehnt, 4000 0025 0000 3155 = 3D Secure Challenge erforderlich, 4000 0000 0000 9995 = Unzureichendes Guthaben.
Für SEPA-Lastschrift und Kauf auf Rechnung müssen Entwickler Webhook-Events manuell auslösen können — da echte Bankverarbeitungszeiten in der Sandbox nicht simuliert werden. Dokumentieren Sie den Test-Endpunkt: POST /v1/sandbox/trigger-webhook mit dem Parameter "event": "payment.success" und "order_id": "...".
Stellen Sie Test-SKUs bereit, die spezifische Fehler auslösen: TEST-SKU-OUT-OF-STOCK = Bestand 0 (inv_001), TEST-SKU-LIMITED-3 = Nur 3 verfügbar (inv_002), TEST-SKU-RACE = Simuliert Race Condition (409 race_condition).
Den Checkout-Endpunkt mit ShippyPro Versand verbinden
Ein erfolgreicher Checkout ist erst der Anfang: Sobald order.paid bestätigt ist, muss der Versandprozess nahtlos anlaufen. Die ShippyPro Versandplattform bietet eine direkte API-Integration, die es erlaubt, auf das payment.success-Webhook-Event zu reagieren und automatisch einen Versandauftrag bei DHL, DPD, Hermes oder GLS zu erstellen — ohne manuelle Zwischenschritte.
Über die ShippyPro-API können Sie Bestelldaten aus Ihrem Checkout direkt in einen Versandauftrag übersetzen: Lieferadresse, Paketgewicht und -maße, gewählter Versanddienstleister und DHL-Wunschlieferpräferenzen werden in einem einzigen API-Call an ShippyPro übergeben. Die vollständige Dokumentation aller verfügbaren Endpunkte — inklusive POST /v1/shipments, Tracking-Webhooks und Rücksendungsmanagement — finden Sie in der ShippyPro API-Dokumentation. Für die Anbindung Ihres bestehenden Shop-Systems ohne eigene API-Entwicklung nutzen Sie die über 80 verfügbaren ShippyPro-Integrationen. Die Track & Trace-Funktion sendet Ihren Kunden automatisch DSGVO-konforme Versandbenachrichtigungen per E-Mail oder SMS — ohne zusätzliche Entwicklungsarbeit.
ShippyPro API-Dokumentation
Vollständige technische Referenz aller ShippyPro-Endpunkte — Shipments, Tracking, Returns, Webhooks — mit Code-Beispielen für die direkte Checkout-Integration.
Dokumentation öffnen →ShippyPro Versandplattform
Verbinden Sie Ihren Checkout-Endpunkt direkt mit DHL, DPD, Hermes und GLS — automatische Versandauftragerstellung nach payment.success-Webhook.
KI-Versandautomatisierung
Automatisieren Sie die Carrier-Auswahl nach Checkout: Webhook empfangen → Versanddienstleister automatisch selektieren → Label generieren → Tracking aktivieren.
Automatisierung ansehen →Track & Trace
DSGVO-konforme Versandbenachrichtigungen automatisch nach Checkout-Abschluss — E-Mail und SMS, vollständig ohne zusätzliche Entwicklungsarbeit konfigurierbar.
Track & Trace ansehen →Ressourcen & Entwickler-Guides
Technische Leitfäden, Webinare und Best Practices für API-Integrationen im DACH-E-Commerce — von Checkout bis Retoure.
Ressourcen ansehen →Integrationen
Über 80 vorgefertigte Shop-System- und Marktplatz-Integrationen — für Händler, die Checkout-zu-Versand ohne eigene API-Entwicklung verbinden möchten.
Integrationen entdecken →Wie implementiere ich PCI-DSS-Compliance für den Checkout-Endpunkt?
Moderne APIs akzeptieren keine rohen Kreditkartennummern direkt. Ihre Dokumentation muss erklären, dass das Frontend die Karte zunächst über ein Payment-SDK (z. B. Stripe Elements, Adyen Web Components) tokenisieren muss und ausschließlich den resultierenden payment_token (z. B. tok_123abc) an den Checkout-Endpunkt übergibt. Damit bleibt Ihre API vollständig außerhalb des PCI-DSS-Geltungsbereichs. Für 3D Secure 2.0 muss das Frontend zusätzlich Browser-Fingerprint-Daten im browser_info-Objekt übergeben — diese werden für die DSP2-konforme Risikoanalyse benötigt.
Was passiert, wenn der Bestand während des Checkout-Calls ausläuft?
Dokumentieren Sie Ihre Race-Condition-Logik explizit. Standardverhalten sollte sein: Die API gibt einen 409 Conflict-Fehler mit dem Fehlercode inv_001 zurück und identifiziert exakt, welcher Artikel nicht mehr verfügbar ist ("sku": "ARTIKEL-123", "available_qty": 0). Das Frontend kann damit den Warenkorb automatisch aktualisieren und den Nutzer informieren — ohne die gesamte Checkout-Seite neu laden zu müssen.
Kann ich eine Bestellung nach erfolgreichem Checkout noch ändern?
Grundsätzlich nein. Sobald /v1/checkout mit 201 Created antwortet und der Zahlungsstatus paid oder pending_payment ist, ist die Bestellung für den Client unveränderlich. Änderungen erfordern entweder einen separaten POST /v1/orders/{id}/cancel-Call (nur wenn noch nicht versendet) oder Kundendienst-Intervention. Dokumentieren Sie das Stornierungszeitfenster explizit: Nach DHL-Übergabe (Statuswechsel zu shipped) ist eine Stornierung nicht mehr möglich — nur noch eine Rücksendung über ShippyPro Easy Return.
Wie teste ich SEPA-Lastschrift und Kauf auf Rechnung in der Sandbox?
Für SEPA-Lastschrift verwenden Sie die Test-IBAN DE89370400440532013000 für eine erfolgreiche Zahlung. Das payment.success-Webhook-Event muss manuell über den Sandbox-Endpunkt POST /v1/sandbox/trigger-webhook ausgelöst werden, da echte SEPA-Verarbeitungszeiten (1–3 Werktage) nicht in der Sandbox simuliert werden. Für Kauf auf Rechnung nutzen Sie die Test-E-Mail-Adresse aus Ihrer Klarna- oder Ratepay-Sandbox-Konfiguration — die Genehmigung erfolgt in der Sandbox immer sofort (keine echte Bonitätsprüfung).
Wie integriere ich DHL Packstation als Lieferadresse im Checkout?
DHL Packstation erfordert eine spezifische Adressstruktur, die sich von normalen Hausadressen unterscheidet: Im shipping_address-Objekt muss street = "Packstation", house_number = die 6-stellige Packstation-Nummer und postal_code = die PLZ der Packstation sein. Zusätzlich muss preferred_delivery.type = "packstation" gesetzt sein. Validieren Sie die Packstation-Nummer client-seitig über die DHL-Standort-API, bevor Sie den Checkout-Call absenden — ungültige Packstation-Nummern führen zu einem addr_packstation_invalid-Fehler.
Eine Shipping-API, die Entwickler lieben
Die ShippyPro-API ist für den DACH-Markt optimiert — mit vollständiger Dokumentation für SEPA-Lastschrift, Kauf auf Rechnung, DHL Packstation und DSP2/3D Secure. Registrieren Sie sich kostenlos und erhalten Sie sofort Zugang zu allen Endpunkten und der Sandbox-Umgebung.
Kostenlosen API-Zugang sichern →
Das Produktteam von ShippyPro hat sich der Entwicklung innovativer Technologien verschrieben, die es Unternehmen ermöglichen, ihre Versandabläufe zu vereinfachen. Durch die Kombination von Kundenforschung mit modernster Technologie entwickeln wir Funktionen, die die Effizienz steigern, den Aufwand reduzieren und die logistische Flexibilität erhöhen.