Skip to content

feat: add one-off charge support (POST /billing/payments/charge/)#11

Merged
BenKalsky merged 1 commit into
mainfrom
feat/one-off-charge
May 1, 2026
Merged

feat: add one-off charge support (POST /billing/payments/charge/)#11
BenKalsky merged 1 commit into
mainfrom
feat/one-off-charge

Conversation

@BenKalsky
Copy link
Copy Markdown
Member

Summary

Adds buildOneOffChargePayload for SUMIT's one-off charge endpoint (/billing/payments/charge/), alongside the existing recurring builder. The same SingleUseToken produced by <SumitCheckout /> works for both endpoints.

What's new

  • buildOneOffChargePayload(params) — builds the one-off request body. Items include Item.Name / Item.Description, Quantity, UnitPrice, Currency — no Duration_Months / Recurrence.
  • normalizeChargeResponse(response) — exposes the existing normalizer under a name that reflects what it actually does (handles both one-off and recurring responses). normalizeRecurringChargeResponse is kept as an alias for back-compat.
  • Shared baseChargeEnvelope helper to keep Credentials / Customer / SingleUseToken / VATIncluded / OnlyDocument / AuthoriseOnly consistent across builders.
  • Type-level: OneOffChargeItem / RecurringChargeItem / BuildOneOffChargePayloadParams / SumitOneOffChargePayload.

Why

Response normalization was already provider-shape-agnostic, so the only real gap was the request builder. A one-off success now naturally surfaces as eventType: "payment.succeeded" (no recurringItemId).

Test plan

  • pnpm test — 16/16 passing (3 new tests: one-off payload shape, alias identity, one-off success normalization)
  • pnpm typecheck clean
  • pnpm build clean

Follow-up (separate PR)

sumit-react's createSumitChargeRoute will get a mode: "recurring" | "oneOff" option that switches both the builder and the upstream URL.

🤖 Generated with Claude Code

Adds a builder for `POST /billing/payments/charge/` (one-off charge)
alongside the existing recurring builder. Items omit the recurring-only
`Duration_Months` and `Recurrence` fields; everything else (Credentials,
Customer envelope, SingleUseToken, VATIncluded, OnlyDocument,
AuthoriseOnly) is shared via a small `baseChargeEnvelope` helper.

Response normalization is unchanged — the existing logic already
handles both shapes since one-off and recurring responses share the
`Payment.*` envelope. Exposed as `normalizeChargeResponse` to make the
one-off use case discoverable; `normalizeRecurringChargeResponse` stays
as an alias for back-compat.

Updated README, CLAUDE.md, and API reference. All 16 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@BenKalsky BenKalsky merged commit 5988a4e into main May 1, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant