CIT / MIT - Information Requests & Recurring Payments

Overview

The classic workflow for a payment is to create a Client Initiated Transaction (CIT), where the buyer interacts with the merchant and triggers the transaction.

However, in some cases, the buyer is not directly interacting with the merchant. Instead, the merchant initiates the transaction—this is called a Merchant Initiated Transaction (MIT).

These transactions are useful for:

• Recurring payments
• Subscriptions
• Any use case where the buyer is not directly involved in the payment process

The Purse API V2 supports both CIT and MIT workflows.

CIT Enabling Future MIT

To enable future MIT, the merchant must create a payment with the allow_future_usage flag set to true. You must also add the challenge_indicator field with the value CHALLENGE_REQUESTED_BY_MERCHANT
to ensure a strong authentication is performed during the initial CIT transaction.

Strong authentication required

The initial Client Initiated Transaction (CIT) must be authenticated with 3DS using the CHALLENGE_REQUESTED_BY_MERCHANT flag
in order to be eligible for future Merchant Initiated Transactions (MIT).

When allow_future_usage is set to true, the client session amount can be set to 0 to trigger an information-only transaction. This transaction is only used to check cardholder authentication and card validity.

{
  "amount" : 0,
  "allow_future_usage": true,
  [...] // Order - Shipment - Customer...
  "three_ds_authentication_options": {
      "challenge_indicator": "CHALLENGE_REQUESTED_BY_MERCHANT"
    }
}

Partner transactions created during this client session will be marked as future-usage and will be usable for future MIT (if the partner supports MIT).

Once the payment linked to the client session is AUTHORIZED, the partner transactions at $.authorization.partner_transactions[] are reusable for future MIT.

{
    "authorization": {
        "status": "AUTHORIZED",
        "partner_transactions": [
        {
            "id": "1a14962c-bdcf-49d1-8673-e75dfb48013f",
            "status": "AUTHORIZED",
            "amount": 2000,
            "partner": "aci",
            "method": "creditcard",
            "partner_reference": "6898f79aa20af",
            "partner_status": "1",
            "partner_status_description": "Successful operation"
        }
        ]
    }
}

Schematic of a CIT transaction

• User initiates a transaction on the merchant website (can be a zero amount order).
• Purse API V2 receives the Client Session information.
• 3DS Authentication is performed if required.
• Authentication checking is processed through the banking network.
• API receives the authorization response.
• Payment ID is stored to be used as parent_payment_id for future Merchant Initiated Transactions (MIT).

Once authorization is confirmed, the payment is marked as authorized.

Information Request

Every CIT transaction requires authentication to ensure security and compliance.

MIT - Creating a Recurring Payment

A Merchant Initiated Transaction (MIT) occurs when the merchant processes a payment without direct user interaction, typically using a previously authorized Payment ID from a Customer Initiated Transaction. (CIT)

To trigger an MIT, the merchant needs to create a payment (/v2/payments) referencing partner transaction id or parent payment id.

Important

We remind that for credit card payments, 3DS authentication must be performed to successfully create future MIT transactions.
CIT/MIT mode is not available for all payment methods. Be sure to check the payment method capabilities in the partners reference section before using this feature.

Mandatory Rules

• The parent_partner_transaction_id or parent_payment_id must always reference the initial CIT authorization transaction or payment.
• Only one of parent_partner_transaction_id or parent_payment_id can be used at a time—never both simultaneously.

Schematic of a MIT transaction

• Merchant initiates the payment using the previously stored parent_payment_id from a successful CIT.
• Purse API V2 receives the payment request with the reference to the parent_payment_id.
• Authorization request is sent to the acquiring bank, skipping 3DS authentication since user interaction is not required.
• The bank checks and validates the authorization.
• API receives the authorization response.
• Payment is confirmed and processed, funds are settled accordingly.

Example: Creating a Merchant Initiated Transaction (MIT)

{
  "entity_id": "5e3a0862-7cc3-4427-92ba-9e1e9595f571",
  "amount": 12000,
  "currency": "EUR",
  "capture_mode": "MANUAL",
  "split": [
    {
      "amount": 12000,
      "parent_partner_transaction_id": "1a14962c-bdcf-49d1-8673-e75dfb48013f",
      "parent_payment_id": "363964fa-8196-11ef-8eab-327d4a6ae82c"
    }
  ],
  [...] // Order - Shipment - Customer...
}