Change Details

This is a diagram of our end-to-end credit card payment submission via Gravy. **Covers**: - Page load and checkout session creation - Secure Fields iframe rendering - Form submission - Two-phase fraud filtering (pre-auth and post-auth), - Authorisation call via SmashPig to the Gravy API - 3DS redirect handling - Fraud REVIEW path (authorised but not captured), - Capture call via SmashPig to the Gravy API - Queue message creation (payments-antifraud, pending, donations). **Notes**: - The edge cases are disruptive but important to capture. - I didn't go into great detail about the client-side JavaScript flow. We could add that too for visibility.

This is a diagram of our end-to-end credit card payment submission via Gravy including the webhook flow **Donation diagram covers**: - Page load and checkout session creation - Secure Fields iframe rendering - Form submission - Two-phase fraud filtering (pre-auth and post-auth), - Authorisation call via SmashPig to the Gravy API - 3DS redirect handling - Fraud REVIEW path (authorised but not captured), - Capture call via SmashPig to the Gravy API - Queue message creation (payments-antifraud, pending, donations). **Webhook diagram covers:** - Webhook receipt and validation (Basic auth header check) - Message parsing and type normalisation - Status normalisation via ResponseMapper (config mappers/cc-response) - Authorization webhook (PENDING_POKE) with conditional capture-from-ipn-listener branch - Capture webhook (COMPLETE) and RecordCaptureJob creation - Async job processing: pending DB lookup, Gravy API call for full transaction details - Pending record enrichment (processor info, donor details, recurring token) - Donations queue push and pending record resolution

This is a diagram of our end-to-end credit card payment submission via Gravy. including the webhook flow **C**Donation diagram covers**: - Page load and checkout session creation - Secure Fields iframe rendering - Form submission - Two-phase fraud filtering (pre-auth and post-auth), - Authorisation call via SmashPig to the Gravy API - 3DS redirect handling - Fraud REVIEW path (authorised but not captured), - Capture call via SmashPig to the Gravy API - Queue message creation (payments-antifraud, pending, donations). **Notes**: - The edge cases are disruptive but important to capture. - I didn't go into great detail about the client-side JavaScript flow.Webhook diagram covers:** - Webhook receipt and validation (Basic auth header check) - Message parsing and type normalisation - Status normalisation via ResponseMapper (config mappers/cc-response) - Authorization webhook (PENDING_POKE) with conditional capture-from-ipn-listener branch - Capture webhook (COMPLETE) and RecordCaptureJob creation - Async job processing: pending DB lookup, Gravy API call for full transaction details - Pending record enrichment (processor info, donor details, We could add that too for visibility. recurring token) - Donations queue push and pending record resolution