Market checkout payment-provider adapters.
This is intentionally scoped to native Market checkout collection. It is not the general Payments Protocol; a future protocol can replace this namespace as the thing Market calls to collect a checkout.
Market checkout payment-provider adapters. This is intentionally scoped to native Market checkout collection. It is not the general Payments Protocol; a future protocol can replace this namespace as the thing Market calls to collect a checkout.
(active-provider-id)(assert-provider-configured!)Fails fast when the configured payment provider cannot actually be honoured.
active-provider-id silently downgrades an explicitly configured "stripe" to
"stub" when no Stripe key is set. A deployment that asked for Stripe would then
produce fake successful checkouts: the buyer sees success, no money moves, and
nothing anywhere reports an error. That is a worse failure than refusing to
start, so this throws.
Only the divergence is an error. Explicitly choosing stub, or leaving the whole thing unconfigured in local dev, is a deliberate choice and passes silently. Returns nil when the configuration is coherent.
Fails fast when the configured payment provider cannot actually be honoured. `active-provider-id` silently downgrades an explicitly configured "stripe" to "stub" when no Stripe key is set. A deployment that asked for Stripe would then produce fake successful checkouts: the buyer sees success, no money moves, and nothing anywhere reports an error. That is a worse failure than refusing to start, so this throws. Only the divergence is an error. Explicitly choosing stub, or leaving the whole thing unconfigured in local dev, is a deliberate choice and passes silently. Returns nil when the configuration is coherent.
(complete-seller-connection {:keys [code]})(configured-provider-id)(create-account-link opts)(create-checkout-session {:keys [provider-id checkout-id buyer game-name
line-items success-url cancel-url
on-behalf-of]})(create-connected-account opts)(create-refund opts)(create-seller-checkout-session
{:keys [connected-account-id checkout-id checkout-batch-id buyer game-name
commerce-adapter fulfillment-ref line-items application-fee-amount
application-fee-bps market-subscription-id plan-sku return-url
idempotency-key]})Creates a seller-owned payment group. This intentionally has no stub fallback: reporting a paid credit purchase when no direct charge exists would create unbacked credits.
Creates a seller-owned payment group. This intentionally has no stub fallback: reporting a paid credit purchase when no direct charge exists would create unbacked credits.
(create-transfer opts)(handle-stripe-webhook
{:keys [raw-body signature webhook-secrets expected-game-name
submit-service-event fallback-game-name verify-seller-payment
upsert-connect-account update-connect-account-by-external-id log-fn]})(payment-mode)(start-seller-connection {:keys [client-id redirect-uri state]})(stripe-account-deauthorized-response
{:keys [account-id update-connect-account-by-external-id event-created
log-fn]})(stripe-account-updated-response {:keys [account upsert-connect-account
update-connect-account-by-external-id
event-created log-fn]})Handles account.updated for a PLAYER account: stamps (owner-id, game-name) in metadata and upserts the (owner, game) payout record.
House (treasury) accounts are NOT handled here. They stamp metadata[account]
(e.g. @intergraph) and are owned end-to-end by MoM's own
treasury-stripe-webhook-handler at /webhooks/stripe/treasury, which is treasury-
authoritative. The GM holds no treasury credential, so upserting one from here
returned 403 — and, being a 5xx, invited Stripe to retry it for days. Ignored with
a 200 instead.
Handles account.updated for a PLAYER account: stamps (owner-id, game-name) in metadata and upserts the (owner, game) payout record. House (treasury) accounts are NOT handled here. They stamp metadata[account] (e.g. @intergraph) and are owned end-to-end by MoM's own `treasury-stripe-webhook-handler` at /webhooks/stripe/treasury, which is treasury- authoritative. The GM holds no treasury credential, so upserting one from here returned 403 — and, being a 5xx, invited Stripe to retry it for days. Ignored with a 200 instead.
(stripe-charge-backfill-response {:keys [event-id charge submit-service-event
fallback-game-name log-fn]})(stripe-dispute-response
{:keys [event-id event-type dispute connected-account-id verify-seller-payment
submit-service-event fallback-game-name log-fn]})Handles charge.dispute.created / charge.dispute.closed. Opening a dispute
freezes the affected orders and records it — no ledger movement, because the
money has not actually left and comes back if we win. Closing it resolves:
won unfreezes, lost additionally routes the amount through the
externally-initiated refund path, since the funds really did leave.
Handles charge.dispute.created / charge.dispute.closed. Opening a dispute freezes the affected orders and records it — no ledger movement, because the money has not actually left and comes back if we win. Closing it resolves: `won` unfreezes, `lost` additionally routes the amount through the externally-initiated refund path, since the funds really did leave.
(stripe-refund-response {:keys [event-id event-type event-created charge refund
connected-account-id verify-seller-payment
submit-service-event fallback-game-name
log-fn]})Handles charge.refunded / refund.updated. A refund carrying our metadata[refund-id] settles that refund (idempotently — redelivery is expected); anything else is reconciled as an externally-initiated refund against the checkout.
Handles charge.refunded / refund.updated. A refund carrying our metadata[refund-id] settles that refund (idempotently — redelivery is expected); anything else is reconciled as an externally-initiated refund against the checkout.
(stripe-session-completed-response opts)(stripe-subscription-deleted-response
{:keys [event-id subscription connected-account-id submit-service-event
fallback-game-name verify-seller-payment log-fn]})Handles customer.subscription.deleted — a cancellation, whether initiated by the buyer, the seller, or Stripe itself after failed payments. Cancels on our side so no further cycle can mint an order.
Handles customer.subscription.deleted — a cancellation, whether initiated by the buyer, the seller, or Stripe itself after failed payments. Cancels on our side so no further cycle can mint an order.
(stripe-subscription-invoice-paid-response
{:keys [event-id invoice connected-account-id submit-service-event
fallback-game-name verify-seller-payment log-fn]})Handles invoice.paid for a renewal or immediate prorated plan change.
subscription_cycle and subscription_update are routed here. The first cycle
also fires invoice.paid — with billing_reason subscription_create — and it is
already recorded by checkout.session.completed. Handling both would mint two
paid orders for one payment and pay commission twice, so this filter is the
only thing standing between a subscriber and being double-billed on day one.
It is asserted in the tests for that reason.
Routing metadata comes off the SUBSCRIPTION, because an invoice arrives with neither a session nor the original PaymentIntent.
Handles invoice.paid for a renewal or immediate prorated plan change. `subscription_cycle` and `subscription_update` are routed here. The first cycle also fires invoice.paid — with billing_reason subscription_create — and it is already recorded by checkout.session.completed. Handling both would mint two paid orders for one payment and pay commission twice, so this filter is the only thing standing between a subscriber and being double-billed on day one. It is asserted in the tests for that reason. Routing metadata comes off the SUBSCRIPTION, because an invoice arrives with neither a session nor the original PaymentIntent.
(stripe-subscription-updated-response
{:keys [event-id subscription connected-account-id submit-service-event
fallback-game-name verify-seller-payment log-fn]})(stripe-transfer-reversed-response {:keys [event-type transfer
submit-service-event log-fn]})Handles transfer.reversed/transfer.failed: reads the withdrawal-id + player-name stamped in the transfer metadata and asks the GM to reverse the pending ledger reservation back to the player (idempotent via the withdrawal-id).
Handles transfer.reversed/transfer.failed: reads the withdrawal-id + player-name stamped in the transfer metadata and asks the GM to reverse the pending ledger reservation back to the player (idempotent via the withdrawal-id).
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |