WinkPG speaks Stripe. Drop in your existing server-side Stripe code, swap the base URL, and you're live. One-shot charges, saved cards, refunds, and the full recurring-billing surface — Products, Prices, Subscriptions, Invoices — with the same resource shapes, ID prefixes, idempotency rules, and webhook signatures you already wire. Migrate in a base-URL change, not a quarter.
# Create + confirm a payment in one call curl https://dx-api.winkpg.com/v1/payment_intents \ -H "Authorization: Bearer sk_test_..." \ -H "Idempotency-Key: order_abc" \ -d 'amount=1050' \ -d 'currency=usd' \ -d 'confirm=true' \ -d 'payment_method_data[type]=card' \ -d 'payment_method_data[card][number]=4111111111111111' \ -d 'payment_method_data[card][exp_month]=12' \ -d 'payment_method_data[card][exp_year]=2028' \ -d 'payment_method_data[card][cvc]=111'
Same resource shapes, same pi_ / pm_ / cus_ ID prefixes, same Idempotency-Key behaviour, same Stripe-style HMAC webhook signatures. Most server-side Stripe SDK code is portable with just a base-URL swap.
Authorize, confirm, capture, refund, void, increment auth — every state transition is a PaymentIntent action. Extension fields surface the underlying op (post-settlement refund vs pre-settlement reversal vs offline void) so you can reconcile with the processor.
Signed webhooks with exponential-backoff retry. Test/live key separation with publishable-key scoping for browser callers. Cursor-based pagination on every list endpoint. Idempotent POSTs on the entire surface — replay-safe by default.
Click any resource to open the live console with that group pre-selected.
The charge lifecycle, end-to-end. Create, confirm, capture, cancel, update, increment_authorization.
Tokenized cards (wallets roadmapped). Attach to a Customer for off-session reuse.
Buyers in your system. Anchor for saved cards and recurring billing.
Save a card without charging it. Use when you'll bill later.
Return funds. refund_operation tells you whether it landed as a refund, reversal, or offline void.
Every state transition is an Event. Same payload that goes to your webhook endpoints.
Register HTTPS URLs to receive signed event POSTs. Rolling secrets, exponential-backoff retry. _test fires a synthetic event for receiver-side iteration.
Catalog items — the parent of one or more Prices. Lives at the dx-winkpg layer.
How much, in what currency, on what cadence a Product is billed. Recurring Prices fuel Subscriptions.
Recurring agreement on a Price. Trials, pause/resume, cancel-at-period-end. Test-mode _advance fast-forwards billing.
Generated each billing cycle. Phase A: read-only — preview next, list past. Create / void / pay land in Phase B.
Apple Pay, Google Pay, Paze, and PSD2 SCA flows. Reserved in the spec; not viable today.
WinkPG matches Stripe's wire shape on the endpoints listed below. If your code already uses these, the migration is a base-URL change plus a key swap. We've also been explicit about what's not yet there — no surprises in production.
next_action is always null. EU/UK PSD2 use cases
aren't viable today.
PaymentIntent create / confirm / capture / cancel / update / increment_authorizationPaymentMethod create with raw card / attach / detachCustomer CRUD with metadataSetupIntent for save-now / charge-laterRefund create / list, with refund_operation reconciliationProduct & Price catalog — recurring or one-timeSubscription create / pause / resume / cancel-at-period-end, with trial periodsInvoice upcoming preview & list — synthesised from WinkPG contract execution historyEvent + WebhookEndpoint with DxWinkPg-Signature HMAC-SHA256Idempotency-Key · publishable-key scopingnext_action never populated501 unsupported_payment_methodinvoice.create / void / pay — Phase BSwap the SDK host, re-issue keys, point your webhook endpoint. We walk a typical Express server through the diff.
BuildPaymentIntentsServer-side confirm: true for card-in-form flows. ~80 LOC Node, no client tokenization needed.
DxWinkPg-Signature headerWorked example with the rolling secret, the timestamp window, and an HMAC-SHA256 comparison that's safe against timing attacks.
RecurringProduct → Price → Customer → attached PaymentMethod → Subscription, in 6 calls. Then use _advance to fast-forward billing in test mode.
The API surface and the consoles ship independently. Subscribe to get the diff in your inbox.
Subscribe →expand[] on GET /v1/customers and GET /v1/customers/{id}. Two expandable fields: payment_methods and subscriptions (prefix with data. on List). Stack them in one call to inline both an attached-cards list and a subscriptions list — saves two follow-up calls per customer.POST /v1/webhook_endpoints/{id}/_test — dx-winkpg extension to fire a synthetic dx_winkpg.webhook_test event at one endpoint. Useful for iterating on signature verification in your receiver.Product, Price, Subscription, Invoice. 16 new endpoints, including a test-mode POST /v1/subscriptions/{id}/_advance that fast-forwards billing for one subscription. Phase A invoices are read-only; create / void / pay arrive in Phase B.sk_test_ key, switch resources from the right rail, runs against the dev gateway.DxWinkPg-Signature: t=<unix>,v1=<hmac> — Stripe-style. Endpoint secrets prefixed whsec_.400 idempotency_error.refund_operation + cancellation_operation now surface on Refund / PaymentIntent so you can tell post-settlement refunds from pre-settlement reversals.