Consult a bill by digitable line
Consults a bill by its digitable line without paying it: the source’s own view of the amount, the dates and who receives the money.
Why POST for a read. The digitable line identifies a payable bill and is sensitive, so it travels in the body instead of the URL, where proxies, logs and browser history would keep it. Nothing is created or changed: the request carries no Idempotency-Key and repeating it is safe.
Local validation first. The line must be 47 digits for a bank slip or 48 digits starting with 8 for a utilities bill, digits only and never normalized: any other form is refused with 400 PBP-0001 before any check digit is computed. A line in the right form whose check digits do not match is refused with 422 PBP-0100. Neither reaches the source.
Segments differ. Every member of the answer is always present; a member the segment does not report is null. A bank slip reports payability, the face value, fine, interest, discount, the due and limit dates, the beneficiary and the receiving bank. A utilities bill reports the assignor, its segment, the state, the payment window and a settlement date, which is not a due date. A bank slip the source does not know is 404 PBP-0110; a utilities line the source does not know is refused with 422 PBP-0111.
Permission. The operation requires payments/create, the same permission as initiating a payment: consulting is the first step of paying.
Isolation. The tenant and the provider credential come from the token, never from the request. The X-Organization-Id header is required and validated in form (a canonical UUID); it does not scope the consult, which reads no stored data of any organization.
Encabezados
Cuerpo
Respuesta
OK

