Payment integration feasibility matrix
- Before
- No confirmed native payment-extension route
- After
- 21 experiments mapped
Shopify commerceClient work
A Payment Provider Shopify Doesn’t Support: Finding a Working Path
I mapped 21 payment-integration experiments and built a server-verified payment continuation, with sandbox results separated from merchant acceptance.
The brief
Context
A Shopify merchant needed a payment provider that was not available through the normal supported integration path. Before building a checkout flow, I needed to establish which surfaces were available and how an external payment could safely update a Shopify order.
I started with a feasibility spike, then built the payment continuation and its settlement backend.
Sounds familiar?
Symptoms
The investigation
Diagnosis
I mapped 21 experiments across native payment extensions, checkout and post-checkout surfaces, hosted payment routes and fallback architectures. The matrix includes blocked and research-only routes. It is not a claim that all 21 completed successfully.
-
The settlement test exposed another boundary: the available Shopify development stores refused the buyer’s manual-payment checkout path. I could test settlement against unpaid manual orders created through the Admin API, but that did not prove the full buyer journey on the merchant’s store.
Handover
What I built
Delivery noteDelivered Pilot backend documented live in September 2026; merchant acceptance unverified
The chosen continuation starts with an unpaid Shopify order created through a manual payment method. A block on the Thank You or Order Status page opens the provider’s hosted payment page. Card details stay on that hosted page.
The server verifies payment before marking the Shopify order paid. Never trust the return URL: I read the provider’s current order status, apply the paid update only when it is confirmed, then read the Shopify order back to check that Shopify agrees.
Signed webhooks, the buyer’s return and a scheduled reconciliation sweep can each trigger the same settlement logic. Duplicate handling and a shared settlement guard prevent those paths from making repeated paid updates.
The handover documentation covers terminal settings, payment-status access for automations, retries and the limits of the integration. A refund at the provider does not automatically become a Shopify refund; the merchant still controls that decision.
Before → after
Results
Client work Done for real clients. Client details are anonymised.
-
-
Concurrent settlement attempts in a recorded sandbox test
- Before
- Duplicate payment updates needed a guard
- After
- 48 concurrent attempts, one paid mutation
The full results table
| Scope | Observed result | Read on |
|---|---|---|
| Feasibility work | A matrix of 21 experiments; native entitlement blocked | September 2026 |
| Sandbox settlement | Confirmed provider payment followed by Shopify paid-status read-back | 11 September 2026 |
| Duplicate-settlement test | 48 concurrent operator attempts, plus webhook and return processing, produced one paid mutation | 11 September 2026 |
| Failure handling | Declined, expired and cancelled payments stayed unpaid; replayed webhooks did not make another paid update | 11 September 2026 |
| Backend release | Health and running-code checks recorded on the deployed backend | 15 September 2026 |
Notes on the numbers
The settlement record is a partial technical result. It does not establish the full storefront buyer path or merchant acceptance. The deployment record still called for a fresh merchant order and visual acceptance.
This is a hosted payment continuation. Native payment-extension approval and App Store distribution are separate steps.
A note from Daniilbefore you decide
What this means for a similar business
The useful outcome of a payment spike is a route with clear evidence and clear limits. I separate an available UI surface, a confirmed payment, Shopify’s recorded financial status and the merchant’s acceptance. Each needs its own check.
— Daniil
Have a similar task?
Describe your taskThe first answer is free, within one working day. Or write directly: next@taskfordaniel.com