PayRails: Payment Evidence Passport

EdgeLock PayRails™ — Payment Evidence Passport

Inspiration

A payment confirmation tells you that money moved. It often leaves the harder questions unanswered: What was being purchased? Which merchant and website were involved? What checks happened before payment? What evidence remains if the transaction is disputed? I built PayRails: Payment Evidence Passport to preserve that context alongside the payment lifecycle.

What it does

PayRails connects purchase context, policy decisions, and PayPal transaction evidence in a persistent Payment Evidence Passport. It validates merchant descriptors and website URLs, applies purchase authorization checks, and correlates the purchase reference with PayPal order and capture IDs. It distinguishes pending, approved, and completed states so an approval is not mistaken for a completed payment. The Passport helps explain what happened and provides evidence that can support later review or dispute preparation. It does not guarantee fraud prevention or a successful dispute outcome.

How I built it

PayPal Sandbox integration and PostgreSQL persistence. The payment adapter handles order creation, buyer approval, capture, and webhook verification. Idempotent reservations and database safeguards protect against duplicate processing and conflicting requests. An evidence-grounded deterministic fallback generates the payment summary. Live AI composition was not verified for this submission.

Challenges I ran into

The main challenge was keeping application state consistent with the payment provider. Buyer approval, capture completion, retries, and webhook delivery are separate events.

We addressed malformed provider responses, invalid OAuth token types, idempotency conflicts, and database finalization failures. We also worked to preserve useful evidence without exposing credentials or unnecessary sensitive information.

Accomplishments that I am proud of

I completed a real USD 1.00 PayPal Sandbox create → buyer approval → capture flow and persisted the completed capture evidence in PostgreSQL. No live funds were used. Validation passed across 74 API tests, including 61 PayPal-specific tests, plus 18 web tests, 26 safety checks, and seven policy tests. Both builds passed, and secret scans found no leaks.

What I learned

Reliable payment automation requires explicit state transitions, consistent reference correlation, and careful handling of retries. We also learned that explanations are most useful when grounded in recorded evidence. A deterministic fallback provides a clear, testable baseline while live AI composition remains unverified.

What's next for PayRails: Payment Evidence Passport

Next, I plan to verify live AI composition against the same evidence constraints, improve the Passport review and export experience, and test additional payment failure and recovery scenarios. We also want merchant feedback on whether the preserved context makes transaction review and dispute preparation easier.