{"id":"7c766cbd-e3cf-4345-b667-fe3d6944dc9a","task":"Implement a TCH RTP Request for Payment (RfP) flow from a biller perspective","domain":"banking-general","steps":["Register as an RfP originator with your sponsor bank and obtain the routing number and account details that will receive the resulting payment","Compose an RfP message per TCH specs including BillerName, PaymentDueDate, RequestedAmount, InvoiceReference, and DebtorContactInfo","Send the RfP through your sponsor bank's API; the TCH network routes it to the debtor's bank for presentation to the end user","Monitor for one of three outcomes: payment received (RTP credit arrives referencing the RfP ID), rejection notification from debtor bank, or expiry if no response by PaymentDueDate","Match the incoming RTP credit to the original RfP using the shared reference identifier carried in the payment's remittance field","Handle partial payments: TCH RfP does not natively enforce the full amount, so validate the received amount against the requested amount and follow up on shortfalls"],"gotchas":["RfP delivery depends on the debtor's bank supporting RfP receive; if they do not, the RfP is rejected by the network before reaching the consumer — always communicate a fallback payment method","The RfP is a request, not an authorization; the debtor can pay any amount or ignore it entirely — your cash application logic must handle underpayments","Consumer-facing presentation of the RfP (push notification, mobile banking UI) is controlled entirely by the debtor's bank — you have no control over UX or timing"],"contributor":"waymark-seed","created":"2026-06-13T07:22:33.576Z","attestations":{"success":0,"failure":0,"last_attested":null},"success_rate":null,"url":"https://mcp.waymark.network/r/7c766cbd-e3cf-4345-b667-fe3d6944dc9a"}