feat(core): gateway-agnostic PaymentProvider interface (Stripe adapter + mock)#18
Open
moset15 wants to merge 1 commit into
Open
feat(core): gateway-agnostic PaymentProvider interface (Stripe adapter + mock)#18moset15 wants to merge 1 commit into
moset15 wants to merge 1 commit into
Conversation
…nd mock Adds a gateway-agnostic payment seam so additional processors (e.g. Paystack for the African market) can plug in without touching core checkout code: - payment-provider/types.ts: the PaymentProvider interface — init hosted checkout, verify webhook (constant-time, algorithm-agnostic), parse webhook event into a normalised shape, refund, format amount. - payment-provider/stripe-provider.ts: thin adapter implementing the interface over the existing stripe/* modules — no changes to any file under src/stripe/. - payment-provider/mock-provider.ts: in-memory implementation for tests and credential-free local checkout runs. - payment-provider/registry.ts: runtime provider selection via settings:paymentProvider (plugin KV), defaulting to "stripe" so existing installs behave identically. - New ./payment-provider subpath export + tsdown entry. - 19 unit tests (bun test) across the three new modules; tsc --noEmit clean; Biome formatted. Routes (checkout.ts / webhook.ts) still call stripe/* directly — wiring them onto resolveProvider() is staged as a follow-up commit so this diff stays reviewable and behaviour-neutral. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Introduces a payment seam so processors beyond Stripe can plug into core without forking it:
initCheckout(hosted),verifyWebhook(constant-time, hash-algorithm-agnostic),parseWebhookEvent(normalised event shape),refund,formatAmount.Why
We are building a Paystack provider (cards + M-Pesa STK — the dominant payment rail in Kenya) for a production store on DashCommerce. Paystack's webhook signing is HMAC-SHA512 and its checkout is hosted-page-first, so the seam is deliberately shaped around what both gateways share rather than around Stripe's API surface.
What this PR does not do
src/stripe/*is untouched — the Stripe adapter (payment-provider/stripe-provider.ts) wraps the existing modules.routes/checkout.tsandroutes/webhook.tsstill callstripe/*directly; wiring them ontoregistry.resolveProvider()is staged as a follow-up commit so this diff stays reviewable and behaviour-neutral (the registry defaults to"stripe", so existing installs behave identically).payment-provider/types.ts).Testing
19 unit tests (
bun test) across types/adapter/mock/registry;tsc --noEmitclean; Biome formatted;tsdownbuild emits the new./payment-providerentry.Happy to reshape the interface if you'd prefer different seams — the Paystack implementation living at FIKANOVA/dashcommerce-paystack is the second consumer and keeps this honest.
🤖 Generated with Claude Code