Technical Glossary

Access Token (Authorization)The OAauth 2 Access token needed to access PayEx' eCom APIs. Tokens are generated in PayEx Admin. Learn how to getting started in the Admin Manual.
AccountReceivableConsumer (Invoice API)The AccountReceivableConsumer API is the fundament for PayEx Web Invoice service. It is a service where PayEx helps produce and distribute invoices to consumers/end-users.
Authorization (transaction)The first part of a two-phase transaction where a certain amount is blocked on the payer's account. The authorized amount is unavailable for the consumer, ensuring that the merchant receive the money during the subsequent capture phase.
Callback (PayEx)If CallbackURL is set a Callback is triggered when a change or update from the back-end system are made on a payment or transaction. PayEx performs a callback to inform the payee/merchant about this kind of update.
Cancellation (transaction)
Used to cancel authorized and not yet captured transactions. If a cancellation is performed after doing a part-capture, it will only affect the not yet captured authorization amount.
Capture  (transaction)The second part of a two-phase transaction where the authorized amount is sent from the payer to the payee. It is possible to do a part-capture on a subset of the authorized amount. Several captures on the same payment are possible, up to the total authorization amount.
Checkin (PayEx Checkout)Checkin is the first part of the PayEx Checkout flow (prior to displaying the Payment Menu), where the payer is identified by email and mobile phone number.
ConsumerThe person doing the purchase, equivalent to Payer.
Consumers (Resource)The Consumers resource stores information about the consumer/payer of the sold services or goods. It is the fundament of Checkin in PayEx Checkout.
FinancingConsumer (Invoice API)The Financing Invoice API  is the fundament for PayEx Invoice service. It is a service where PayEx helps improve cashflow by purchasing merchant invoices. Reccuring payments / Invoice billing is supported by this servce.
Header (API)A HTTP header used to carry information when doing an API Request. All API requests share some common headers.
Intent (option)

An intent is a payment parameter that determine the possible activity states available for a payment option (e.g. Purchase). Intents differ depening on payment instrument. Creating a payment within a one-phase payment flow (Swish, direct debit) must have the intent to create a Sale  - this in contrast to a two-phase payment flow that have the intent to create an Authorization. Card payments also have specific intents that determine whether an AutoCapture is implemented (the credit card is charged directly like one-phase transaction) or if a PreAuthorization should be made. The example below shows a Payout payment that is autocaptured.   

    "payment": {
        "operation": "Payout",
        "intent": "AutoCapture",
MOTO (order typ parameter).An abbreviation of the parameter mailOrderTelephoneOrder,  that is available when posting a payment or paymentorder. The parameter should be set to true if the payment or payment order created is a telephone or mail order.  
One-phase payment flow.A payment done in one step. The amount is settled in one transactional step.
Operation  (payment option)

A  payment operation determines what kind of payment that should be implemented. Available payment operations vary, depending on payment instrument. The most common operation all instruments share is the Purchase operation. Credit cards have several others, such  as Payout, Verify and Recur.

    "payment": {
        "operation": "Purchase",
Operations (transactional)

Operations consist of an array of contextual links / actions that direct the payment flow in a given state of the payment resource (i.e. creating a capture transaction, creating a reversal transaction, returning a redirect URL, etc). Operations are HATEOAS driven and managed through API calls.

"operations": [
        "href": "<paymentId>/captures",
        "rel": "create-capture",
        "method": "POST"
PayeeThe company that receive funds for the payment.
Payee IDThe ID of the company that receive funds for the payment. May also be known as Merchant ID.
PayerThe person doing the purchase, equivalent to Consumer.
PayEx Admin (admin account)The eCommerce Admin interface where you perform day to day operations on payments processed by PayEx. The Admin manual consists of two parts, Getting Started and Interface and Search.
PayEx Direct API (platform)A payment flow where the implementer (PayEx customer) handles all user intreraction and make direct API calls to PayEx (server-to-server).
PayEx Hosted ViewA payment flow were the consumer interact with pages developed by PayEx directly through an iframe, directly embedded in the webshop/merchant site. 
PayEx Payment Pages  (platform)A payment flow where the consumer get redirected to a payment page developed and hosted by PayEx.
Payment (resource)A payment is the main resource in all of PayEx' RESTful APIs, and a fundamental building block for each payment instrument during the payment process. The payment resource of each payment instrument is architectually similar, although tailor-made to manage the specifics of each instrument. It can be in different states and contain several different types of transactions. The state of the payment decides the operations that are available
Payment MenuA hosted view - embedded on a website - showing available payment instruments during payment scenario. The Payment Menu is the second part of the PayEx Checkout flow (after checkin).
Payment Orders(resource)The Payment Orders resource is used when initiating a payment process using the Payment Menu and PayEx Checkout. What payment instrument the payment order will make use of is up to the payer. The payment order is a container for the payment method object selected, acessed through the sub-resources payments and currentPayment.
Payment token (token)A payment token is generated through a card purchase or card verification. It contains all necessary payment details to enable subsequent server-to-server payments. Used in One-click payments and recurring payment scenarios (for card, invoice and Payex Checkout) .
Payout (Option)The payment option that initiates a payout payment process. A Payout payment is a deposit directly to credit card.
Purchase (Operation)The payment operation that initiates a purchase payment process.
Recur (Operation)The payment operation that initiates a recurring payment process. It is a payment that references a recurrenceToken created through a previous payment in order to charge the same card.
Reversal (transaction)Used to reverse a payment. It is only possible to reverse a payment that has been captured and not yet reversed.
Sale (transaction)A one-phase transaction where the amount is settled when the transaction has succeded. Payment instruments using sales transactions are Swish and Direct Bank Debit.
Two-phase payment flow.A payment done in two steps. Authorization and capture. The most common payment instrument using two-phase payments is card payments.
Verify (Operation)The payment operation that initiates a verification payment process. It is a payment that lets you post verifications to confirm the validity of card information, without reserving or charging any amount. This option is used to generate a payment- or recurrence token, that can be used in a recurring payments scenarios or for one-clickpayments, without charging the card in the process. 
Created by Asbjørn Ulsberg on 2019/08/20 14:03