cdf78635f6
All checks were successful
build-and-release / build (customers) (push) Successful in 12s
build-and-release / build (catering-services) (push) Successful in 14s
build-and-release / build (developers) (push) Successful in 16s
build-and-release / build (companies) (push) Successful in 20s
build-and-release / build (employees) (push) Successful in 22s
build-and-release / build (cron) (push) Successful in 23s
build-and-release / build (fitness-trainers) (push) Successful in 9s
build-and-release / build (gateway) (push) Successful in 9s
build-and-release / build (graphic-designers) (push) Successful in 10s
build-and-release / build (job-seekers) (push) Successful in 8s
build-and-release / build (makeup-artists) (push) Successful in 7s
build-and-release / build (photographers) (push) Successful in 10s
build-and-release / build (jobs) (push) Successful in 14s
build-and-release / build (social-media-managers) (push) Successful in 12s
build-and-release / build (tutors) (push) Successful in 11s
build-and-release / build (ugc-content-creators) (push) Successful in 8s
build-and-release / build (users) (push) Successful in 10s
backend-integration-tests / ai-credits (push) Successful in 10s
build-and-release / build-db-migrate (push) Successful in 14s
build-and-release / build (video-editors) (push) Successful in 15s
build-and-release / build (payments) (push) Successful in 4m2s
/verify only runs if the client's browser makes it back after PayU redirects; a payment that succeeded on PayU's side but whose tab was closed or lost network before redirecting sat at PENDING forever with no server-side path to notice. Adds a poll job (apps/payments/src/reconcile.rs) run every 5 minutes that queries PayU's verify_payment API directly for any payment still PENDING after 15 minutes (giving up after 7 days -- almost certainly an abandoned cart by then, not a missed callback), and finalizes or fails it server-side. Extracts the actual claim-and-credit transaction (SELECT ... FOR UPDATE gated on status = 'PENDING') out of verify_payment into reconcile::finalize_successful_payment, shared by both callers so there's exactly one implementation of the double-credit-proof claim to reason about; it's what makes it safe for the poll job to independently race /verify on the same txnid. Also unifies invoice/notification side-effects into finish_successful_payment_side_effects, drawing billing contact from `users` rather than the client-supplied /verify payload (the poll path has no such payload, and it's the more correct source of truth for the GST invoice either way). |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| Dockerfile | ||