Glossary
The words this documentation uses for the things WinkPG does, defined once. Where a term has a page of its own, the entry links to it.
No definition here carries a number. How long an authorization lives, how long you have to answer a dispute, and how much you may add as a surcharge are all set by a card brand, an issuer, or a regulator rather than by this platform, and they differ per merchant. Each entry says who decides instead.
The life of a card payment
The stages a card transaction moves through, in the order they happen.
Authorization
A request asking the cardholder's issuing bank to set aside funds for a purchase. An approval reserves the amount and reduces the credit available on the card, but it moves no money. An authorization nobody captures expires on a schedule the card brand and the issuer set, not one you choose.
Capture
The step that tells the issuer to collect an amount that was authorized. You can capture the full amount or less than it, and capturing less releases the remainder of the authorization. Nothing reaches the merchant's bank until a captured transaction settles.
Batch
The set of captured transactions a merchant sends for settlement together, usually once a day. The batch boundary is the line between the two ways of undoing a transaction: inside the open batch you can void, and after it closes you can only refund.
Settlement
The movement of money from the issuing banks to the merchant's bank for the transactions in a closed batch. It happens on the processor's schedule rather than on the merchant's, so a transaction can be approved today and settle days later.
Void
Cancels a captured transaction before it settles, so it never appears on the cardholder's statement at all. A void is only possible while the batch is still open, which is why the same correction is a void in the morning and a refund the next day.
Reversal
Releases an authorization you have decided not to capture, returning the reserved amount to the cardholder's available credit straight away. Without one the hold stays on the card until the issuer expires it, and the cardholder sees money they can't spend.
Refund
Returns money to the cardholder after a transaction has settled. A refund is a transaction in its own right, with its own identifier and its own settlement, so the original charge stays on the statement and the return appears beside it.
Partial approval
An issuer response approving less than you asked for, which happens on prepaid and some debit cards carrying too small a balance. The transaction succeeds for the approved amount, so an integration that treats approval as payment in full will under-collect unless it reads the approved amount back and either takes the difference another way or reverses what was approved.
How the card reaches you
Where the card details come from decides which rules apply and what the transaction costs.
Card present
A transaction where a terminal reads the card with the customer standing there, by chip, contactless tap, or magnetic stripe. The card brands treat these as the lowest fraud risk, and they usually cost the merchant the least to accept.
Card not present
A transaction where the card details arrive without the card: an API call, a hosted payment page, or an order taken over the phone. The merchant carries more of the fraud liability, which is why the address and security-code checks below matter more here than at a terminal.
Stored payment method
A card or bank account a customer has agreed the merchant may keep and use again. WinkPG keeps the account number and hands the merchant a payment token to charge instead, so a later charge needs no account number and no re-entry by the customer.
Customer-initiated transaction (CIT)
A transaction the customer is present for and actively approves, such as a checkout where they pick a stored payment method and select Pay. A CIT is what establishes the agreement that later charges without the customer rely on.
Merchant-initiated transaction (MIT)
A transaction the merchant runs against a stored payment method with the customer absent, such as a scheduled installment or a delayed top-up. An MIT has to reference the agreement a customer-initiated transaction established, and issuers decline more of the ones that don't.
Checks that come back with an approval
Two results that arrive alongside the approval and tell you how much to trust it. Neither one declines a transaction on its own.
Address Verification Service (AVS)
A check comparing the numeric parts of the billing address and postal code you send against what the issuer holds. The issuer answers with a match code rather than a decline, so what a mismatch costs a customer is your integration's decision and not the issuer's.
Card verification value (CVV)
The short security code printed on the card, which proves whoever is paying had the card in hand. WinkPG collects it on every card-entry surface and never stores it, and the issuer returns a match result you can act on the same way you act on an address mismatch.
Two kinds of token
Both stand in for an account number and the two aren't interchangeable. What separates them is who issues the substitute and who can refresh it.
Payment token
An identifier WinkPG issues in place of a card or bank account number, so a merchant can charge a stored payment method again without ever holding the number. A payment token belongs to the merchant that created it unless it's shared with another on purpose.
Network token
A card number substitute issued by the card brand rather than by WinkPG, which the brand keeps current when the underlying card is reissued. That's what it buys you: a repeat charge survives the card expiring or being replaced, which a stored card number doesn't.
Bank account payments
Money moved between bank accounts rather than over a card network, on a delay that changes what a success means.
Automated Clearing House (ACH)
The network that moves money between bank accounts in the United States. An ACH payment isn't authorized in real time the way a card is, so an accepted request means the payment was submitted rather than that the funds are good.
ACH return
A notice from the receiving bank that an ACH payment couldn't be completed, arriving days after the payment appeared to succeed. Every return carries a code saying why, and the code decides whether you may retry the payment or must stop asking.
Disputes
What happens when the cardholder, rather than the merchant, asks for the money back.
Chargeback
A forced reversal the cardholder starts by disputing a transaction with their own bank instead of asking the merchant. The money is pulled back along with a fee, and the merchant has a window set by the card brand to answer with evidence.
Fees added at the checkout
Two fees that look alike on a receipt and are governed by different rules. Getting the pair the wrong way round is a compliance problem rather than a billing one.
Surcharge
A fee added to a credit card transaction to offset what accepting cards costs the merchant. The card brands cap it, forbid it on debit and prepaid cards, and require the customer be told before they pay, and some jurisdictions prohibit it outright.
Convenience fee
A flat fee for paying through a channel that isn't the merchant's usual one, such as paying a bill online you would normally pay in person. Unlike a surcharge it applies whatever the payment method, including debit, which is what makes the two different obligations rather than two names for one.
Environments
Every merchant has both. A key belongs to exactly one of them and carries which one in its own value.
Sandbox
The test environment. Its keys are prefixed sk_test_, its transactions answer from a simulator rather than reaching a card network, and no money moves. Every card number you use here comes from the testing guide.
Production
The live environment. Its keys are prefixed sk_live_, and every transaction reaches a real processor and a real cardholder. A key's environment is fixed when it's created, so a key sent to the wrong environment is refused rather than downgraded.