What it means

Your request payload violated the EPC Verification of Payee schema. The check can happen at the gateway (pre-routing) or at the upstream VOP provider — the effect is the same: the request was not processed. Read the X-Rejected-By-Provider header to tell where the rejection originated.

When you'll see it

• A top-level field is unknown to the EPC 267-24 schema (typo in a property name).
• A field has the wrong type — for example a string where an object is expected.
• A required structural element (party, partyAccount) is missing.
• Character encoding is not UTF-8 or the JSON body does not parse.
• A nested field exceeds its declared schema bound (similar shape to VALIDATION_FAILED but originating upstream).

Example response

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

How to fix

1. Inspect X-Rejected-By-Provider — if true, the upstream VOP provider found the problem; if false, PreVOP did.
2. Compare your payload against the OpenAPI specification and the EPC 267-24 schema it is derived from.
3. Check that all required fields are present and correctly nested (party / partyAccount / identification).
4. Verify the request body is UTF-8-encoded JSON with Content-Type: application/json.
5. Fix the malformed field and resend the request with a fresh X-Request-ID.

Related

• Customer API Contract §4.2 — PreVOP error codes (FORMAT_ERROR row)
• See also: VALIDATION_FAILED — same shape of failure, but caught at the PreVOP gateway before the request reaches the provider.