PayConexDecryptxShieldConexTECS Platform
API Reference
Request SandboxContact Us

Customer/Merchant Initiated Transactions Use Case

Overview

Customer initiated transactions (CIT), as the name suggests, are initiated by the customer, usually as CNP or CP transactions. Examples include online purchases, in-store purchases and mobile payments.

🚧

Note

MIT transactions are processed based on a prior agreement with the customer by reissuing a SALE with the MIT parameters. See Customer and Merchant Initiated Transactions.

MITs play a crucial role in situations where the merchant needs to charge the customer on a regular basis or perform transactions without requiring repeated customer interactions. These transactions reduce friction for customers by eliminating the need for repeated manual entries.

Other Use Cases

Compared to the zero-amount authorization and the Recurring Payments Use Case, there can be a CIT when a subscription or similar requires immediate payment confirmation. Here, we introduce the MIT/CIT parameters and their workflow.

CIT/MIT Transaction Flow

The following diagram illustrates the process for handling CITs and MITs. CITs are sales transactions, such as one-time online purchases, bill payments, and initial transactions to set up a recurring payment agreement. The merchant server applies CIT parameters to notify the card issuers that the transaction is initiated by the customer. The same applies for MITs when it comes to recurring subscription payments, installment payments and account top-ups.

CITs are processed by either Card Present (CP) or Card Not Present (CNP) transactions with CPs always being customer-initiated.

PayConexâ„¢ CIT/MIT Transaction Flow

PayConexâ„¢ CIT/MIT Transaction Flow

  1. CIT Processing: The customer agrees to the recurring payments and processes a CIT. The merchant server/ECR makes a request via PayConexâ„¢ V4 API.

  2. Detokenization/Decryption: Either Decryptx® or ShieldConex® can play a role where CP/MOTO transactions follow the Decryptx® workflow and CNPs follow the ShieldConex® workflow.

  3. Forwarding: Decryptx®/ShieldConex® forwards the decrypted or detokenized elements to the PayConex™ services.

  4. Processor Authorization: These then proceed to the Payment Processor for authorization.

  5. Distinction of Transaction Type: The Payment Processor informs the card issuers to distinguish between CITs and MITs, waiting for approval or decline.

  6. Issuer Approval: The card issuers send the status (approve/decline) back to the Payment Processor, which then communicates with PayConexâ„¢.

  7. Auto-Tokenization: On the way back, ShieldConex® is also involved for auto-tokenization during CIT processing.

  8. Vaulting: In the case of CIT, the token is vaulted for subsequent MITs.

  9. Reissuing Token: The origin (merchant server/ECR/POS systems) receives the reissuing token.

    • Recurring Cycle: The MIT process continues as long as there are recurring payments with ShieldConex® as the main solution to extract and detokenize the sensitive data from the token. During this iteration, there is no Auto-Tokenization and Vaulting.

📘

Note

*Account top-ups are Unscheduled Credential on File MITs.

The services legends suggest that Bluefin can either provide the solutions or allow the merchant to develop them independently, as Bluefin vaults and supplies the reissuing token in the response of a CIT. For example, this feature can be set via the PayConex v3.8 API SLAPI or from the PayConexâ„¢ Portal via UI tools -> RECURRING BILLING.

If a merchant is a large ISV, they may opt to use their own recurring service/solution.

We also support the billPayment parameter in a transaction. This allows a merchant to specify the additional recurring data or installment data for the Payment Processor and the card issuers. For the extra parameters, see Processing a Sale or API Reference.