# Stage: Make Payment & Failure Handling

Once a PMM is chosen, the trade moves to the `MAKE_PAYMENT` stage, where the PMM must transfer payment to the user and submit a `paymentTxId`. Submissions can be made by the `Solver` or the PMM to ensure transparent tracking and auditability. Failure to make the payment before `scriptTimeout` may lead the `MPC` to mark the trade as `FAILURE`.

### <mark style="color:orange;">Solver Responsibilities</mark>

* **Initiating Payment Submission (Optional):** Assist in submission if needed.
* **Monitoring PMM Activity:** Ensure payment is submitted on time.

### <mark style="color:orange;">PMM Responsibilities</mark>

* **Fulfilling the Payment:** Transfer funds via an approved method.
* **Submitting `paymentTxId`:** Publicly submit a verifiable transaction ID.
* **Signature Authentication:** Use cryptographic signatures for authenticity.
* **Acting Within `tradeTimeout`:** Complete payments before the deadline to avoid penalties.
* **Retrying After Warning:** Resubmit necessary payments to correct failed trades.

### <mark style="color:orange;">Successful Payment Submission</mark>

A valid `paymentTxId` submission within `scriptTimeout` moves the trade forward, clears previous failures, and emits a `MadePayment` event. Delays beyond the `tradeTimeout` deadline can lead to rejection by the `MPC`.

### <mark style="color:orange;">Failure: No Payment Submitted & Timeout</mark>

If no valid `paymentTxId` is submitted by `scriptTimeout`, the trade is stalled. The `MPC` may use the `report()` function to mark it as failed.

### <mark style="color:orange;">Functions and Event Emissions</mark>

#### `makePayment()` Function

* **Permissioned Execution:** Can be called by the authorized `Solver` or PMM via the `Router`.
* **Trade Stage Validation:** Ensures correctness of stage and clears failures on valid retries.
* **Timeout & Expiry Checks:** Validates against `scriptTimeout`.
* **Signature Verification:** Confirms PMM’s signature for authenticity.
* **Trade State Transition:** Advances to `CONFIRM_PAYMENT` and logs submission time.
* **Event Emission:** Emits a `MadePayment` event for validation.

#### `report()` Function

If a payment is unsuccessful before `scriptTimeout`, the `MPC` reports the failure:

* **Permissioned Execution:** Executable by authorized `MPC Node` via the `Router`.
* **Constraints & Behavior:** Ensures trade's validity for reporting.
* **Signature Verification:** Uses EIP-712 for authenticity.
* **Trade State Transition:** Stores failure details and marks trade as `FAILURE`, allowing user refunds.
* **Event Emission:** Emits a `FailureReported` event for monitoring.

### <mark style="color:orange;">Queryable Trade Data</mark>

#### Successful Payment

* **Get Trade Stage:** Returns current trade stage (e.g., `CONFIRM_PAYMENT`).
* **Get Trade Finalization:** Provides finalization details and `paymentTxId` for audit.

#### No Payment & Timeout

* **Get Trade Stage:** Shows current stage (e.g., `FAILURE`).
* **Get Failure Details:** Provides error metadata, including stage and reason.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.optimex.com/optimex-revolutionizing-bitcoin-finance/optimex-swap/optimex-swap-how-it-work/trade-life-cycle/optimex-l2-network/stage-make-payment-and-failure-handling.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.