Provider receipt

A provider receipt is evidence returned by an external service after a property-management system asks it to do something. It may come from a payment processor, messaging carrier, screening provider, e-signature platform, listing network, or maintenance vendor system. The receipt connects the internal request to the provider’s record and reports an accepted, rejected, pending, or completed state.

A useful receipt preserves the provider name, provider-assigned identifier, internal action or idempotency identifier, request time, response time, status, relevant nonsecret response fields, and any later status changes. It should not store access tokens, full payment credentials, or unnecessary applicant data. The receipt is evidence of what the provider reported; it is not independent proof that a tenant read a message, funds finally settled, or repair work was satisfactory.

For example, a rent payment request receives an “accepted” response with transaction ID 8K4. That receipt proves the processor accepted the request. The workflow remains pending until settlement or return events arrive. Marking the tenant ledger paid immediately would confuse request acceptance with final money movement. Later events should reference the same provider identity so the full lifecycle can be reconstructed.

Receipts matter during retries and disputes. If a call times out, the system uses the same idempotency identity or queries the provider before sending another instruction. If internal state and provider state disagree, the receipt enters reconciliation or an exception queue. Preserve the raw or normalized response with timestamps and provenance, but describe its evidentiary limit honestly.