Build on WinkPG
Everything you need to integrate payments, stored payment methods and reporting against this WinkPG instance. The reference below is generated from the API this installation serves, so what you read here is what you can call.
What are you building?
Start from the thing you are trying to do. Each scenario names the short path, the guide behind it, and a blueprint you can run against a sandbox merchant.
- Accept a payment online Take a card payment from a web or mobile checkout. The first decision is where the card fields live, because it decides both how much you build and what you have to prove every year. Compare the three paths below.
- Decision guide Choose an integration method
- Guide Embedded payments compared with in-page card collection
- Blueprint Accept your first payment
- Invoice a customer Draft an invoice, issue it to lock and number it, then send it so the payer can settle it from a link. The blueprint walks the lifecycle against your sandbox; the API reference carries the rest of it.
- Blueprint Invoice a customer and get paid
- API reference Create an invoice
- API reference Send an invoice to the payer
- Charge a saved card, or bill on a schedule Store a payment method against a customer, then charge it again later: at a checkout they're present for, or without them under the consent they gave when it was saved. You keep a token this platform issues, never the card number.
- Guide Reusing saved cards
- Blueprint Save a card and charge it later
- Blueprint Bill a customer on a schedule
- Take a payment over the phone An agent reads the card into your own system, so the card number reaches your servers. This is the case that genuinely needs the direct API, and it is scoped accordingly.
- Quickstart Quickstart: direct API
- Guide Getting started with the API
- Blueprint Accept your first payment
- Build on webhooks A payment's durable record arrives as a webhook rather than as the response to your own call. Verify the signature, answer quickly, and make the handler safe to run twice.
- Quickstart Quickstart: webhooks
- Guide Webhook integration
- Blueprint Receive and verify webhooks
Choosing how to collect the card
Three paths take a card online, and they differ far more in what you have to prove every year than in how much code they take to write.
| Path | Who renders the card fields | What it means for your scope | Record of the payment | Start with |
|---|---|---|---|---|
| Hosted payment page | We do, on a page we serve. Your checkout redirects to it, or embeds it in an iframe. | Smallest of the three. No system of yours transmits, processes or stores the card number, and the single-use session address is the only capability the browser holds. | The webhook. A payer who closes the tab after paying never reaches your redirect. | Quickstart: hosted payment page |
| Embedded payment fields | We do, inside a frame your page mounts and cannot read. The payer stays on your checkout and sees no redirect. | Your page never receives the card number, and nothing in it authenticates. Your checkout page itself stays in scope for the scripts it loads beside the frame. | The webhook. The browser lifecycle event is for display only. | Quickstart: embedded payments SDK |
| Direct API | You do. The card number reaches your own servers before they send it to us. | Largest of the three. Every system the card number passes through is in scope, including logs, queues and backups. | The charge response tells you the outcome, and the webhook is still the durable record. | Quickstart: direct API |
For what each path means for your annual evidence, walk the integration-method decision guide. For how an embedded payment session differs from an older in-page card script, read the comparison guide.
Start here
One short path per integration route, from nothing to a working call. Pick the one that matches how you want to collect the payment.
API resources
WinkPG API version v1, 729 endpoints.
Billing & Invoicing
- Invoicing Invoice generation, tracking, and payment reconciliation.
- Merchant Billing Reseller-to-merchant billing: billing runs and history, plan-scoped reporting, and the stored payment method used to draft recurring charges.
- Recurring Billing Recurring billing for customer contracts: triggering a run by hand, and the history of runs already executed.
Customers & Contracts
Identity & Access
- Account Sign-in account self-service: registration, password reset, email and phone confirmation, and profile management.
- API Keys API key lifecycle for programmatic access: issuing a key, revealing it once, rotating it, and deactivating or deleting it.
- Developer Portal Back-office management of Developer Portal access: the accounts that grant it and the invitations that offer it. Every operation is scoped to the acting merchant.
- Login Interactive sign-in and sign-out: password authentication, external login linking, and the password re-check a sensitive operation asks for.
- My Session Self-service listing and revocation of the signed-in user's own active login sessions.
- Roles Roles, and the claims attached to them. A role is how a set of permissions is granted to every user assigned it.
- Security Overview Reads the security posture of an account, and of a merchant's accounts and API keys, for the security hub.
- User Favorites Per-user favorites API. All reads/writes are scoped to the operating user (impersonated user when impersonating, current user otherwise).
- Users Back-office user administration: creating and maintaining users, assigning their roles and organization units, and managing their active sessions.
Merchants & Resellers
- Merchant Payment Encryption Binding Read or change one merchant's payment encryption provider bindings, and the key serial identifier entries under them, without sending the whole merchant document back.
- Merchant Shipping Binding Read or change one merchant's shipping rate provider bindings without sending the whole merchant document back.
- Merchant Tax Binding Read or change one merchant's tax provider bindings without sending the whole merchant document back.
- Merchant Three DS Binding Read or change one merchant's 3-D Secure bindings without sending the whole merchant document back.
- Merchants Merchant onboarding, configuration, processing settings, and lifecycle management.
- Resellers Reseller partner management, hierarchy, and merchant assignment.
Messaging & Notifications
- Announcements System announcements and banner management.
- Inbound Sms Message Operator access to the inbound SMS log: what recipients replied, and honoring a free-text opt-out that no automated keyword rule interprets.
- Messaging Delivery records for the email and SMS the platform sends on a merchant's behalf, plus the SMS consent register that decides who may be texted.
- Notifications Notification channels, destinations, subscriptions, and delivery tracking.
Payments
- Campaigns Group payment links into a campaign with one status, one schedule and one report.
- Hosted Payment Pages Hosted payment pages: the checkout pages WinkPG hosts on a merchant's behalf, their branding and field configuration, and the sessions a shopper is sent to.
- Promotions Merchant promotion codes: one discount, one validity window and one set of redemption ceilings, shared by hosted pages, contracts and invoices.
- Sandbox Ach Status Drives a sandbox ACH sale to a chosen settlement outcome on demand, so an integrator can prove an ACH webhook in one session.
- Sandbox Settlement Closes a sandbox merchant's open batch on demand, synchronously, for the developer who holds the key.
- Shipping A merchant's ship-from origins and parcel presets: the two inputs a shipping rate quote needs beyond the destination.
- Surcharging Merchant credit-card surcharge configuration and notice filing.
- Tokens Payment token vault and card-on-file management.
- Transaction Statistics The filtered transaction-statistics aggregate: count and total amount over every transaction matching a filter, grouped by transaction type, by payment type and by result code.
- Transactions Payment transaction processing, search, settlement, and reporting.
- Wallets Preview Digital wallet setup and runtime: provider registrations and their platform credentials, Apple Pay certificate provisioning, merchant sessions, encrypted token receipt and the domain association file, Paze certificates and public JWKS, and the checkout snapshot a payment page reads to decide which wallets to offer.
Platform Configuration
- Accounting OAuth Connecting a merchant to an accounting provider over OAuth, and completing the provider's callback.
- Processor Metadata Read-only discovery API that exposes the configuration shape each payment processor requires.
- Rate Limits Stored rate limiting configuration: profiles that bind a set of limits to a scope, and the rules within them that cap request rates, concurrency, and accumulated amounts.
- Screening Provider Metadata Read-only discovery API that exposes the configuration shape each external screening provider requires.
Reporting & Operations
- Audit Log The platform audit trail: who changed what, when, and from where, paged with continuation tokens.
- Health Checks Platform health: the overall status, and the state of the individual components behind it.
- Reports Report generation, scheduling, and export.
- Security Self-service access to the signed-in user's own security log: sign-ins, password changes, and the other identity events recorded against their account.
- Usage Metered usage reporting: period summaries, the underlying ledger entries, and the SKU definitions they are metered against.
The API reference isn't available right now
This instance couldn't load its API specification. The rest of the documentation still works, and the reference returns as soon as the specification is readable again.