> ## Documentation Index
> Fetch the complete documentation index at: https://nextgen-docs.enfuce.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

A transaction lifecycle typically involves several key stages, although the exact flow may **vary** depending on the payment method, the context, or the specific use case. The following diagram shows the key participants in the payment flow.

```mermaid theme={null}
flowchart LR
    Cardholder
    Merchant
    Acquirer
    PS["Payment scheme\n(Visa, Mastercard)"]
    Enfuce["Processor (Enfuce)"]
    Issuer["Ledger"]

    Cardholder <--> Merchant
    Merchant <--> Acquirer
    Acquirer <--> PS
    PS <--> Enfuce
    Enfuce <--> Issuer

    style Cardholder fill:#dbeafe,stroke:#93c5fd,color:#1e3a5f
    style Merchant   fill:#dbeafe,stroke:#93c5fd,color:#1e3a5f
    style Acquirer   fill:#dbeafe,stroke:#93c5fd,color:#1e3a5f
    style PS         fill:#dbeafe,stroke:#93c5fd,color:#1e3a5f
    style Enfuce     fill:#dbeafe,stroke:#93c5fd,color:#1e3a5f
    style Issuer     fill:#dbeafe,stroke:#dc2626,stroke-dasharray:5 5,stroke-width:2px,color:#1e3a5f
```

The lifecycle can be divided into the following phases:

<AccordionGroup>
  <Accordion title="Cardholder Authentication">
    <div style={{marginLeft: '20px'}}>
      <p>In this phase, the authenticity of the person initiating the transaction is verified to check whether they are the legitimate cardholder, using methods appropriate to the payment channel such as PIN entry for POS transactions, 3D Secure and passwords for e-commerce, and biometric or device-based authentication when using digital wallets.</p>

      <p>For more information, see [Cardholder Authentication](/guides/transaction-lifecycle/cardholder-authentication/cardholder-authentication).</p>
    </div>
  </Accordion>

  <Accordion title="Authorisation">
    <div style={{marginLeft: '20px'}}>
      <p>The ledger performs a series of real-time checks, including verification of sufficient funds or credit, as well as validations of technical and business rules, such as spend limits, card status, and expiration date, before approving or declining a transaction.</p>

      <p>For more information, see [Authorisation](/guides/transaction-lifecycle/authorisation/authorisation).</p>
    </div>
  </Accordion>

  <Accordion title="Clearing">
    <div style={{marginLeft: '20px'}}>
      The transaction details are exchanged between the relevant financial institutions to confirm the transaction and prepare for fund transfer.
    </div>
  </Accordion>
</AccordionGroup>

## Functions of Processor and Ledger

Enfuce acts as the payment processor, handling communication with card schemes and validating transactions, while the ledger manages cardholder account balances. The two roles have distinct responsibilities:

* A **processor** communicates with card schemes in real-time, receives transaction messages from the scheme, and processes transaction requests by validating rules and checking spending limits.
* A **ledger** verifies the cardholder's account balance for the card used in the payment.

Other participants in the workflow include systems that send notifications to cardholders' devices or feed data to warehouses.

The following table summarises the responsibilities of Enfuce and the ledger in a typical payment processing workflow:

| Function                                                                                            | Enfuce | Ledger |
| --------------------------------------------------------------------------------------------------- | ------ | ------ |
| Communicate real-time with card Schemes                                                             | ✅      | ❌      |
| Validate technical integrity of Scheme sent messages                                                | ✅      | ❌      |
| Validate the real-time availability of funds and place account holds based on payment messages      | ❌      | ✅      |
| Match linked messages, such as Adjustments, Reversals, or Financial, with the initial authorisation | ✅      | ❌      |
| Process transaction event webhook notifications and adjust account holds accordingly                | ❌      | ✅      |

### Interfaces

Enfuce communicates with the ledger through three distinct interfaces:

1. **Authorisation Request**: Enfuce asks the ledger to verify that sufficient funds are available on the account and, if approved, to place an account hold for the requested amount.
2. **Transaction Event**: Enfuce notifies the ledger of events that have taken place, such as a successful authorisation, a reversal, or an adjustment.
3. **Clearing File**: Enfuce notifies the ledger of all financial transactions that follow from prior authorisations, finalising the amounts to be posted to the account.

## Example sequence

This is an example sequence involving a payment authorisation followed by a partial reversal and then finalised by a clearing message.

```mermaid placement="top-right" theme={null}

sequenceDiagram

    autonumber

    participant PaymentScheme@{ "type" : "boundary" }
    participant Enfuce
    participant Ledger

    rect rgba(240, 240, 240, 0.62)
        note over PaymentScheme,Ledger: Sequence for the initiating authorisation request.
        PaymentScheme->>Enfuce: Payment authorisation request
        note right of Enfuce: Decision step
        Enfuce->>Enfuce: Initial validations (technical, business, fraud)
        rect rgb(230, 245, 255)
            alt If Enfuce technical validations passed
                Enfuce->>Ledger: Send Authorisation Request
                Ledger->>Ledger: Validate balance and create account hold
                Ledger-->>Enfuce: Approve/Decline/Partially Approve the request
            end
        end

        Enfuce-->>PaymentScheme: Response with appropriate response code
        note right of Enfuce: Receipt step
        loop Until successfully acknowledged
            Enfuce->>Ledger: Send TransactionEvent
            Ledger-->>Enfuce: Acknowledge
        end
    end

    rect rgba(240, 240, 240, 0.62)
        note over PaymentScheme,Ledger: Sequence for a partial reversal
        PaymentScheme->>Enfuce: Scheme advice (partial reversal)
        note right of Enfuce: No decision step needed
        Enfuce->>Enfuce: Validate that the card exists, adjust<br/>spend control usage if needed
        Enfuce-->>PaymentScheme: Response with acknowledgement<br/>that the message was processed
        note right of Enfuce: Receipt step
        loop Until successfully acknowledged
            Enfuce->>Ledger: Send TransactionEvent
            Ledger->>Ledger: Adjust the account hold according<br/>to the message content
            Ledger-->>Enfuce: Acknowledge
        end
    end

    rect rgba(240, 240, 240, 0.62)
        note over PaymentScheme,Ledger: Sequence for the clearing transaction
        PaymentScheme->>Enfuce: Clearing file
        note right of Enfuce: Clearing batch processed and transformed<br/>then sent to the ledger
        Enfuce->>Enfuce: Identify matching authorisations and assign correct transactionId.<br/>Remove sensitive cardholder data.
        Enfuce->>Ledger: Send Clearing file
        note right of Enfuce: The clearing file contains multiple clearing<br/>transactions
        Ledger->>Ledger: Find account holds based on transactionId, remove the hold<br/>and post the clearing transaction on the account.
    end
```

### Authorisation

1. The payment scheme sends an authorisation request to Enfuce.
2. Enfuce performs initial validations — technical, business, and fraud checks. If any validation fails, Enfuce returns a decline response to the payment scheme without contacting the ledger.
3. If validations pass, Enfuce sends an Authorisation Request to the ledger, asking it to verify the available balance and place an account hold for the requested amount.
4. The ledger validates the account balance and creates an account hold.
5. The ledger responds to Enfuce, approving, declining, or partially approving the request.
6. Enfuce maps the ledger response to the appropriate scheme response code and forwards it to the payment scheme.
7. Enfuce asynchronously sends a Transaction Event to the ledger to confirm the authorisation message it received and processed.
8. The ledger acknowledges receipt of the Transaction Event.

### Partial Reversal

9. The payment scheme sends a partial reversal advice to Enfuce.
10. Enfuce validates that the card exists and adjusts spend control usage if needed. No decision step is required — the reversal is processed as an advice.
11. Enfuce acknowledges the message to the payment scheme.
12. Enfuce asynchronously sends a Transaction Event to the ledger with the adjustment details.
13. The ledger adjusts the account hold according to the reversal amount.
14. The ledger acknowledges receipt of the Transaction Event.

### Clearing

15. The payment scheme sends a clearing file to Enfuce.
16. Enfuce matches each clearing record with the corresponding authorisation, assigns the correct transaction ID, and removes sensitive cardholder data.
17. Enfuce forwards the transformed clearing file to the ledger.
18. The ledger locates the account holds by transaction ID, removes them, and posts the clearing transactions to the accounts.