Wink Payment Gateway
Wink Payment Gateway

Payments and subscriptions, with the SDK you already know.

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.

PaymentIntents SetupIntents Customers Refunds Subscriptions Invoices Webhooks Idempotency
# 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'
// Works with the official Stripe SDK — just swap the host
const Stripe = require('stripe');
const stripe = Stripe('sk_test_...', {
  host: 'dx-api.winkpg.com',
  protocol: 'https',
});

const intent = await stripe.paymentIntents.create({
  amount: 1050,
  currency: 'usd',
  confirm: true,
  payment_method_data: {
    type: 'card',
    card: { number: '4111111111111111', exp_month: 12, exp_year: 2028, cvc: '111' },
  },
}, { idempotencyKey: 'order_abc' });
# Works with the official Stripe SDK — point api_base at WinkPG
import stripe

stripe.api_key  = "sk_test_..."
stripe.api_base = "https://dx-api.winkpg.com"

intent = stripe.PaymentIntent.create(
  amount=1050,
  currency="usd",
  confirm=True,
  payment_method_data={
    "type": "card",
    "card": {"number": "4111111111111111", "exp_month": 12, "exp_year": 2028, "cvc": "111"},
  },
  idempotency_key="order_abc",
)
POST /v1/payment_intents · 201 Created Run in the console →

Stripe-compatible by design

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.

Full charge lifecycle

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.

Production primitives, day one

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.

The API surface

Eleven resources. 50 endpoints.

Click any resource to open the live console with that group pre-selected.

Full reference →
Compatibility

What ports cleanly from your Stripe integration.

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.

Note: 3-D Secure / PSD2 SCA flows aren't supported yet — next_action is always null. EU/UK PSD2 use cases aren't viable today.
  • PaymentIntent create / confirm / capture / cancel / update / increment_authorization
  • PaymentMethod create with raw card / attach / detach
  • Customer CRUD with metadata
  • SetupIntent for save-now / charge-later
  • Refund create / list, with refund_operation reconciliation
  • Product & Price catalog — recurring or one-time
  • Subscription create / pause / resume / cancel-at-period-end, with trial periods
  • Invoice upcoming preview & list — synthesised from WinkPG contract execution history
  • Event + WebhookEndpoint with DxWinkPg-Signature HMAC-SHA256
  • Stripe-style cursor pagination · Idempotency-Key · publishable-key scoping
  • 3-D Secure / SCA · next_action never populated
  • Apple Pay · Google Pay · Paze — return 501 unsupported_payment_method
  • Multi-item subscriptions, invoice.create / void / pay — Phase B
Featured recipes

Start from a working build.

All recipes →
What's new

Changelog.

The API surface and the consoles ship independently. Subscribe to get the diff in your inbox.

Subscribe →
May 14, 2026
APIStripe-style 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.
May 14, 2026
APIPOST /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.
May 14, 2026
APIRecurring billing lands. New resources: 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.
May 13, 2026
APISurface freeze for the payments lane — 33 endpoints across PaymentIntents, PaymentMethods, Customers, SetupIntents, Refunds, Events, WebhookEndpoints.
May 9, 2026
ConsoleLive API console — paste an sk_test_ key, switch resources from the right rail, runs against the dev gateway.
May 6, 2026
APIWebhook delivery now signs with DxWinkPg-Signature: t=<unix>,v1=<hmac> — Stripe-style. Endpoint secrets prefixed whsec_.
May 1, 2026
APIIdempotency-Key honoured on every POST. Replays return the cached response; mismatched bodies return 400 idempotency_error.
Apr 24, 2026
Fixrefund_operation + cancellation_operation now surface on Refund / PaymentIntent so you can tell post-settlement refunds from pre-settlement reversals.
v0 wireframe