Was es bedeutet

Ihr Request-Payload verletzt das EPC Verification-of-Payee-Schema. Die Prüfung kann am Gateway (vor dem Routing) oder am Upstream-VOP-Provider stattfinden — die Wirkung ist dieselbe: Der Request wurde nicht verarbeitet. Lesen Sie den Header X-Rejected-By-Provider, um den Ursprung der Ablehnung zu erkennen.

Wann Sie diesen Fehler sehen

• Ein Top-Level-Feld ist im EPC-267-24-Schema nicht bekannt (Tippfehler im Property-Namen).
• Ein Feld hat den falschen Typ — z. B. ein String, wo ein Objekt erwartet wird.
• Ein verpflichtendes Strukturelement (party, partyAccount) fehlt.
• Die Zeichencodierung ist nicht UTF-8 oder der JSON-Body ist nicht parsbar.
• Ein verschachteltes Feld überschreitet seine Schema-Begrenzung (gleiche Form wie VALIDATION_FAILED, aber vom Upstream erkannt).

Beispiel-Antwort

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Rejected-By-Provider: true

{
  "type":    "https://errors.prod.prevop.alseda.eu/errors/format-error",
  "code":    "FORMAT_ERROR",
  "title":   "Provider rejected payload as malformed",
  "status":  400,
  "detail":  "Unknown field 'payerName' — expected 'party.name'"
}

So beheben Sie das Problem

1. Prüfen Sie X-Rejected-By-Provider — bei true hat der Upstream-Provider das Problem gefunden, bei false PreVOP.
2. Vergleichen Sie Ihren Payload mit der OpenAPI-Spezifikation und dem zugrunde liegenden EPC-267-24-Schema.
3. Prüfen Sie, ob alle Pflichtfelder vorhanden und korrekt verschachtelt sind (party / partyAccount / identification).
4. Stellen Sie sicher, dass der Request-Body UTF-8-codierter JSON mit Content-Type: application/json ist.
5. Korrigieren Sie das fehlerhafte Feld und senden Sie den Request mit einer neuen X-Request-ID erneut.

Verwandte Themen

• Customer API Contract §4.2 — PreVOP-Fehlercodes (Zeile FORMAT_ERROR)
• Siehe auch: VALIDATION_FAILED — gleiche Art von Fehler, aber vom PreVOP-Gateway erkannt, bevor der Request den Provider erreicht.