Skip to content

Verify Stripe payment before Storefront order capture - #95

Merged
roncodes merged 2 commits into
dev-v0.4.20from
fix/verify-stripe-checkout
Aug 30, 2026
Merged

Verify Stripe payment before Storefront order capture#95
roncodes merged 2 commits into
dev-v0.4.20from
fix/verify-stripe-checkout

Conversation

@roncodes

Copy link
Copy Markdown
Member

Summary

  • bind each Storefront checkout to the PaymentIntent created by the server
  • add a unique nullable Stripe PaymentIntent reference to checkouts
  • retrieve that exact PaymentIntent with the configured gateway secret before any order or transaction writes
  • require succeeded status and matching intent ID, recalculated amount, received amount, currency, customer, and live or test mode
  • replace client supplied transaction identifiers and payment status with verified Stripe values
  • contain provider and authentication failures without exposing Stripe secrets
  • add regression coverage for pending, mismatched, unavailable, unauthenticated, unlinked, and successful verification paths

Verification

  • complete Storefront server unit suite passes
  • checkout boundary suite: 47 tests, 298 assertions
  • PHP syntax checks pass for all changed PHP files
  • PHP-CS-Fixer dry run passes
  • git diff check passes

Migration and rollout

The migration adds a unique nullable stripe_payment_intent_id column to checkouts. Stripe checkouts created before deployment do not have a securely linked intent and will be rejected at capture with HTTP 422; affected customers must restart checkout. This fail-closed behavior avoids accepting an unverified client supplied intent.

API and review notes

Stripe capture can now return:

  • HTTP 402 when payment is not complete
  • HTTP 422 when the intent is missing or does not match the checkout
  • HTTP 502 when Stripe verification is unavailable

The API specification should document these responses. Payment, migration, and transaction behavior require human review before merge.

Static analysis baseline

The repository type command remains blocked by its existing configuration and framework model resolution findings. Targeted analysis confirms that baseline remains present; this PR does not expand into repository-wide static-analysis remediation.

@roncodes roncodes added type:bug Bug fix priority:p0 Critical priority needs-api-spec Requires API specification updates needs-human-review Requires human review before proceeding labels Aug 30, 2026
@roncodes
roncodes merged commit c22fcee into dev-v0.4.20 Aug 30, 2026
@roncodes
roncodes deleted the fix/verify-stripe-checkout branch August 30, 2026 11:53
pull Bot pushed a commit to danielabelski/fleetbase that referenced this pull request Aug 31, 2026
…heckout

Storefront now refuses to capture a Stripe checkout whose PaymentIntent
has not succeeded (fleetbase/storefront#95), and a contract run can never
complete a card payment — so the stripe capture step could only ever
answer 402, and with no order created the pickup and receipt requests
cascaded into 'No order found.'

Resequence the storefront RUN_LATE chain around the collection's new
requests (fleetbase/postman#55): read the stripe checkout (status,
intent update) before anything consumes the cart, assert the 402 refusal
as an explicit negative contract, then initialize and capture a cash
pickup checkout — which needs no provider payment — so the run creates a
real order for Complete Order Pickup and Get Order Receipt. The QPay
callbacks keep addressing the stripe checkout's {{checkout_id}},
unchanged.

Merge AFTER fleetbase/postman#55: RUN_LATE entries are emitted as -i
flags without being matched against files first, so naming requests the
collection does not have yet would abort the whole run with 0 requests
executed.

Validated by running the orderer against the updated collection: the
chain emits in the intended sequence, both new requests resolve, and no
missing-entry warnings are produced.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-api-spec Requires API specification updates needs-human-review Requires human review before proceeding priority:p0 Critical priority type:bug Bug fix

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant