Skip to main content

Glossary

Definitions of the concepts, acronyms, and integration terms used throughout this documentation.

Glossary termDefinition
3DS (3-D Secure)The protocol that authenticates the cardholder during an online card payment, shifting liability for fraud to the issuer.
3DS authentication valueThe proof of authentication produced by 3DS, historically called CAVV (Visa) or AAV (Mastercard). Passed as threeds_authentication_value.
3DS challengeThe step where the customer actively authenticates, for example in their banking app.
Account status checkA zero-amount authorization used only to confirm a card is active.
Account-to-account (A2A)A transfer straight from the customer's bank account to the merchant's, bypassing the card networks. Used by Wero and Pay by Bank.
AcquirerThe bank or processor on the merchant's side that routes the transaction to the networks.
action_dataThe companion object holding the url and, for postform, the fields to submit.
AIS (Account Information Service)The PSD2 service for reading account data with the customer's consent.
API Key / API PasswordThe username and password pair used for HTTP Basic Authentication on every request.
Asynchronous processingThe final status is not in the API response. It arrives later via a postback. Most redirect-based methods work this way.
Attended / unattendedWhether a staff member is present at the terminal. Vending machines are unattended; SoftPOS is always attended.
AuthorizationReserve funds without collecting them. Must later be captured or reversed, or it expires.
B2C / B2BConsumer vs. business variants of SEPA Direct Debit. They use different scheme rules, most notably around the right to refund.
Basic AuthenticationThe scheme where credentials are sent as Authorization: Basic <base64(api_key:api_password)>.
BICBank Identifier Code, identifying the bank. Optional for SEPA IBANs.
camt.053 / MT940 / CDZBank statement file formats used for reconciliation. camt.053 is the ISO 20022 XML standard; MT940 is the older SWIFT format; CDZ is a German variant. Banks deliver settlement and return information in one of these.
CapabilitiesThe entry and verification methods a terminal supports, such as contactlessChip, onlinePin, or noCvm.
CaptureCollect funds from an existing authorization. Can be for the full amount or less (partial capture).
Card network / Card brandThe scheme the card belongs to, such as VISA or MASTERCARD. Returned as card_brand.
card_entryHow the card details were obtained: e-commerce, manual, card-on-file, token, or token-on-file.
Card-on-fileA card stored for reuse, whether as a network token or a referenced transaction.
Cardholder dataThe sensitive card fields together: number, holder name, CVV, and expiry. Handling these directly puts you in PCI DSS scope.
CashbackCash handed to the customer as part of the card transaction, included in the total charged.
charge_orderWhy the card is being charged: checkout, one-click, recurring, ucof, installment, standing-order, and similar. Networks use this to apply the right rules.
ChargebackThe cardholder or their bank disputes a payment that had already succeeded, pulling the funds back out of your account.
Checkout PageA hosted session, created via the Checkout API, where the customer picks from the payment methods you have configured.
checksumA signature included in postback parameters, verified with the Webhook Key.
Child transactionEach individual charge PayPal generates under a subscription, recorded against the original transaction.
CIT (Customer-Initiated Transaction)A charge the customer actively triggers while present, such as a one-click checkout with a stored card.
clear_afterA timestamp after which a manually cleared transaction is captured automatically.
clearing_modeauto captures immediately; manual captures only when you call Capture.
client_actionThe response field telling your integration what to do next: redirect (send the customer to a URL) or postform (build and auto-submit an HTML form, used for 3DS challenges).
CreditorIn SEPA, the party entitled to collect a direct debit.
creqThe 3DS challenge request payload your form posts when client_action is postform.
CRYPTOGRAM_3DSA Google Pay token carrying a wallet cryptogram, which already satisfies authentication.
CVM (Cardholder Verification Method)How the cardholder proves they are the legitimate user: PIN, signature, biometrics, or nothing at all (noCvm) for low-value contactless.
CVV / CVCCard verification value, the digits printed on the card used to prove possession.
DashboardThe web portal where you find credentials and inspect transactions, at testdashboard.betterpayment.de or dashboard.betterpayment.de.
Debt collectionThe process of pursuing an amount that was never paid.
Digital walletAn app or browser feature that stores cards and pays with a tokenized version of them, such as Apple Pay, Google Pay, or Wero.
Directory Server Transaction IDThe identifier tying an authentication to its 3DS session, submitted alongside the authentication value.
DPANDevice PAN. The card number substitute a wallet puts on the device, distinct from the real card.
ECI (Electronic Commerce Indicator)A code recording how much authentication took place, which determines who carries fraud liability.
ECOME-commerce. A card-not-present transaction, where the card is entered online rather than read by a terminal.
EMVThe chip-card standard. EMV data read from the chip is forwarded to the API unaltered.
EMV application cryptogramThe signature generated by the card's chip proving the card is genuine and present. Distinct from a wallet cryptogram.
Execution dateThe date a direct debit collection is actually submitted to the bank, which is not the date you created it.
FactoringSelling the receivable to a third party, who then carries the collection risk. The payment counts as successful for you because the factoring party is assumed to have paid.
FPANFunding PAN. The real underlying card number that a DPAN maps to.
FrictionlessA 3DS outcome where the issuer is satisfied without challenging the customer.
GratuityA tip added after the card is first presented, handled with manual clearing and a later capture for the higher amount.
Hosted Payment PageAny OneAPI-hosted page where the customer enters or confirms payment data.
IBANInternational Bank Account Number, identifying the account.
IdempotencySending a unique key with a request so that retrying it cannot create a duplicate payment. Keys are remembered for one hour.
Incremental authorizationAn authorization that increases the reserved amount on an existing authorized transaction. Currently supported for Apple Pay, Google Pay, Card ECOM, and Card POS.
Integration DataThe Dashboard section, under My Company, holding your API Key, API Password, and Webhook Key.
IrrevocableA transfer that cannot be pulled back once authorized.
IssuerThe bank that issued the customer's card and that approves or declines the authorization.
Managed wallet integrationCheckout Page integration where OneAPI handles the wallet certificates, tokenization, and button rendering on the hosted page. Available for Apple Pay and Google Pay.
Mandate referenceThe identifier for a mandate, quoted on the payer's bank statement so they can recognize the collection.
Manual clearingAuthorizing now and capturing later, rather than doing both at once. Controlled by clearing_mode.
MerchantThe business accepting the payment. Also called the acceptor.
MIT (Merchant-Initiated Transaction)A charge you trigger without the customer present, such as a monthly renewal. The counterpart to a CIT.
MPI (Merchant Plug-In)Your own 3DS provider, if you choose to run authentication yourself instead of letting the gateway do it. See Merchant 3DS Authentication.
Network tokenA permanent substitute for the card number, issued by the card network (Visa, Mastercard). Used for card-on-file and recurring charges without storing the real PAN. See Network Tokenization.
Network token statusWhere a token is in its lifecycle: requested, active, suspended, failed, archive_pending, or archived.
Offline PINThe PIN is verified by the card's chip locally, without contacting the issuer.
Onboarding managerYour contact for Dashboard access and for enabling Optional Services.
OneAPIThe payment gateway through which all payment, refund, and management requests are made.
Online PINThe PIN is encrypted by the terminal and verified by the issuer.
Optional servicesFeatures switched off by default that must be enabled for your account, such as Network Tokenization or Merchant 3DS.
original_transaction_idThe reference to the first transaction in a series, which is how later charges are linked to the stored credential.
PAN (Primary Account Number)The full card number.
PAN_ONLYA Google Pay token holding only a card number. 3DS is still required.
Partial approvalThe issuer approves less than the requested amount, typical with prepaid cards that have insufficient balance.
Pay by LinkOneAPI's pay-by-link product: a shareable link the customer opens to pay, instead of being redirected from your own checkout. Invoices, channels, and installment plans are managed through the Pay by Link APIs.
Payer / Cardholder / CustomerThe person making the payment.
PaymentAuthorize and capture funds in a single step — the most common operation. Splitting into Authorization + Capture instead lets you confirm funds at order time and collect them at shipping time, or adjust the final amount (for example, adding a tip).
Payment Page RedirectThe customer is redirected to a OneAPI-hosted payment page. Sensitive data never touches your servers, so you stay out of PCI DSS scope.
PayoutSend money to a customer with no prior payment to reference. Also called an unreferenced credit transfer.
PayPal PlanThe PayPal object defining a subscription's amount and billing cycle.
PayPal SubscriptionPayPal's own recurring billing. PayPal triggers the charges, not you — the MIT model does not apply. See PayPal.
PCI DSSPayment Card Industry Data Security Standard. The compliance regime that applies once you touch raw cardholder data. Hosted pages and managed wallets keep you out of scope.
PIN blockThe encrypted PIN payload sent for online verification.
PIS (Payment Initiation Service)The PSD2 service for starting a transfer from the customer's account with their consent.
POSPoint of sale. A card-present transaction, where the physical card is read by a terminal.
POS terminalThe device that reads the card and collects the data sent to the API.
PostbackThe HTTP POST OneAPI sends to your server when a transaction's status changes. Also called a webhook. Because a customer may never return to your success_url, this is the authoritative source of final status.
postback_urlYour endpoint that receives postbacks. Must use HTTPS with TLS 1.2 or higher; plain HTTP is rejected.
Pre-notificationThe advance notice the payer must receive before each collection, a scheme requirement.
Production environmentThe live environment at api.betterpayment.de. Credentials are not shared with the test environment.
PSP (Payment Service Provider)The platform processing payments on the merchant's behalf.
reason_codeThe standardized code explaining a return or rejection, such as AC01.
ReconciliationMatching money that arrived in your bank account against the orders it belongs to.
Recurring paymentA repeat charge taken against a stored card or an existing mandate.
RefundReturn money from a completed payment to the customer. A partial refund returns less than the original amount.
RegistrationStore card details for later use without reserving an amount, unlike an authorization. Returns a transaction_id you later pass as original_transaction_id to charge the card.
Return / R-transactionA collection the payer's bank sends back, for insufficient funds, a revoked mandate, or similar.
ReversalCancel an authorization before it has been captured, releasing the reserved funds.
Risk checkA scoring step that can reject a payment before it reaches the acquirer. Failed checks surface as their own error codes.
SCA (Strong Customer Authentication)The PSD2 requirement that certain payments be authenticated. 3DS is how it is satisfied for cards.
SCA exemptionA request to skip authentication for a low-risk payment: tra (Transaction Risk Analysis), low-value, or scp (Secure Corporate Payment). The issuer decides whether to honour it.
SEPASingle Euro Payments Area. The zone in which euro transfers follow one common set of rules.
SEPA Credit TransferA standard push transfer, settling in about a business day.
SEPA Direct DebitPulling money from the payer's account under a mandate they granted.
SEPA export cycleThe batch window in which queued collections are submitted. Collections wait for the next cycle.
SEPA Instant Credit TransferA push transfer settling in seconds. Used by Pay by Bank.
SEPA mandateThe payer's standing authorization allowing you to collect from their account.
Server-to-Server (S2S)Your backend sends payment data directly to the API, with no hosted page. Gives full control of the checkout UI, but puts you in PCI DSS scope when you handle raw card data.
ShopA configured sales channel belonging to a merchant, identified by shop_id. A merchant can have several.
SoftPOSA terminal that is software only, typically a phone app rather than dedicated hardware.
SRC (Secure Remote Commerce)The card-network standard behind Click to Pay, which recognizes the customer by email or mobile number.
status / status_codeThe same transaction state in two forms: status is the readable name (completed), status_code the numeric equivalent (3). Both appear in responses and postbacks. The values themselves are listed in Transaction Status.
Stored transaction_idA past payment identifier from OneAPI used to charge a customer again by referencing the original transaction.
success_url / error_urlWhere the customer is sent back to after a successful or failed payment. Both are required on redirect flows. They control the customer's browser only — the authoritative status arrives by postback.
Terminal actionAn instruction returned mid-transaction telling the terminal to do something more, such as request_pin or switch_interface, after which you retry the call.
Terminal entry modeHow the card was read: chip, contactless, magstripe, magstripe-fallback, or manual-entry.
Test environmentThe sandbox at testapi.betterpayment.de, for building and validating your integration.
TokenizationReplacing a real card number with a substitute value that is useless if stolen. In this documentation, "token" can also mean a network token, a wallet token, a mandate reference, or a stored transaction_id — each replaces or identifies something different.
Track 2 dataThe data encoded on the card's magnetic stripe.
TransactionA single payment or payment-related operation, identified by a transaction_id.
UCOF (Unscheduled Card-on-File)A charge against a stored card that follows no fixed schedule, such as an account top-up. Passed as the charge_order value ucof, which is also the default for recurring card charges.
Unmanaged wallet integrationYou render the wallet button, receive the encrypted token, decrypt it yourself, and send the card data to the API.
VoidAn immediate cancellation. During registration some providers place a small authorization and void it at once, purely to confirm the card is usable.
VoP (Verification of Payee)A check comparing the recipient's name against their IBAN before a transfer is made. The outcome — match, close match, no match, or not applicable — can determine whether a transfer or refund is allowed to proceed. Appears in the Wero refund scenarios.
Wallet cryptogramA one-time cryptographic value proving a wallet token is genuine and unreplayed. Distinct from an EMV application cryptogram.
Wallet tokenA per-transaction substitute for the card number, issued by Apple or Google. Arrives encrypted and must be decrypted unless you use a managed integration.
Webhook KeyThe secret used to sign postbacks, found under My Company → Integration Data. Not the same as your API password — confusing the two is a common cause of failed verification.