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

# Monitoring vs. Reprocessing

Understanding the relationship between **transactional monitoring** and **payment reprocessing** is essential for efficient payment operations. This guide explains the differences, how they interact, and when to use each workflow.

## What is Transactional Monitoring?

Transactional monitoring is the **real-time analysis** of payments as they are processed. It happens **before** a payment is completed.

| **Aspect**      | **Description**                                      |
| :-------------- | :--------------------------------------------------- |
| **Timing**      | During payment processing                            |
| **Purpose**     | Detect fraud, ensure compliance, identify risks      |
| **Trigger**     | Automatic (system-driven)                            |
| **Outcome**     | Approve, flag for review, or block                   |
| **User action** | None (for approval) or submit documents (for review) |

## What is Payment Reprocessing?

Reprocessing is the **manual or automated retry** of a failed payment after the underlying issue has been corrected. It happens **after** a payment has failed.

| **Aspect**      | **Description**                                   |
| :-------------- | :------------------------------------------------ |
| **Timing**      | After payment failure                             |
| **Purpose**     | Successfully complete a previously failed payment |
| **Trigger**     | Manual (user-driven)                              |
| **Outcome**     | Payment succeeds or fails again                   |
| **User action** | Correct data, add funds, then create new payment  |

## Key differences at a glance

| **Feature**               | **Transactional Monitoring**        | **Reprocessing**      |
| :------------------------ | :---------------------------------- | :-------------------- |
| **When it occurs**        | During payment processing           | After payment failure |
| **Who initiates**         | System (automatic)                  | User (manual)         |
| **Payment status**        | Processing, Under Review            | Failed                |
| **Goal**                  | Prevent fraud and ensure compliance | Recover from failures |
| **Requires user action?** | Only if flagged                     | Yes (always)          |
| **Fees charged?**         | Yes (if payment succeeds)           | Yes (each attempt)    |

## How monitoring impacts reprocessing

Transactional monitoring can affect whether a payment is eligible for reprocessing:

| **Monitoring outcome**   | **Can reprocess?**         | **Notes**                                |
| :----------------------- | :------------------------- | :--------------------------------------- |
| **Auto-approved**        | N/A (payment succeeded)    | No reprocessing needed                   |
| **Flagged for review**   | After approval             | Once approved, payment proceeds normally |
| **Blocked (fraud)**      | Not recommended            | Address fraud root cause first           |
| **Blocked (compliance)** | After compliance clearance | Submit documents, await clearance        |
| **Failed (data error)**  | Yes                        | Correct data and create new payment      |

> 💡 Monitoring does not automatically retry failed payments. Reprocessing is always a manual action.

## Payout Manual Data Qualification vs. Payout Reprocessing

These two concepts are often confused. Here is the clear distinction:

| **Aspect**       | **Manual Data Qualification (test)**                      | **Payout Reprocessing**                     |
| :--------------- | :-------------------------------------------------------- | :------------------------------------------ |
| **Definition**   | Pre-validating beneficiary data before creating a payment | Re-attempting a payment after it has failed |
| **Timing**       | Before payment creation                                   | After payment failure                       |
| **Tools**        | Data Collect, PIX key validation                          | Dashboard or API (create new payment)       |
| **Success rate** | Higher (issues caught early)                              | Variable (depends on correction)            |
| **Use case**     | New beneficiaries, bulk payments, prevention              | One-off failures, urgent corrections        |
| **Fees**         | No fee for validation                                     | Payment fees apply per attempt              |

### **Flow diagram**

text

```text theme={null}
Manual Data Qualification (prevention):
   ↓
Beneficiary self-reports data → Validation → Data approved
   ↓
Create payment (higher success rate)

Reprocessing (correction):
   ↓
Payment fails → Identify reason → Correct data → Create new payment
```

## Transactional monitoring impact on your operation

Depending on the risk assessment, a transaction may take different paths:

| **Monitoring outcome** | **Transaction status** | **Impact**            | **User action**  |
| :--------------------- | :--------------------- | :-------------------- | :--------------- |
| **Low risk**           | Processing → Paid      | Normal flow           | None             |
| **Medium risk**        | Under Review           | Temporary hold        | Submit documents |
| **High risk**          | Blocked                | Payment rejected      | Contact support  |
| **MED notification**   | Frozen                 | Investigation started | Provide evidence |

## When to reprocess a payment

| **Scenario**                     | **Reprocess?**    | **How**                                     |
| :------------------------------- | :---------------- | :------------------------------------------ |
| **Beneficiary data incorrect**   | Yes               | Correct data, create new payment            |
| **Insufficient balance**         | Yes               | Add funds, create new payment               |
| **Bank temporarily unavailable** | Yes (wait 1 hour) | Retry after delay                           |
| **PIX key invalid**              | Yes               | Ask for correct PIX key or use bank details |
| **Compliance block**             | After clearance   | Submit documents, await approval            |
| **Fraud block**                  | No                | Investigate root cause first                |
| **Payment already succeeded**    | No                | Check status – do not duplicate             |

## Best practices to minimize reprocessing

| **Practice**                               | **Why it helps**                                            |
| :----------------------------------------- | :---------------------------------------------------------- |
| **Use Data Collect**                       | Beneficiaries self-report, eliminating transcription errors |
| **Validate PIX keys before payment**       | Catches invalid keys early                                  |
| **Maintain sufficient balance**            | Prevents insufficient fund failures                         |
| **Keep KYC documents updated**             | Reduces compliance flags                                    |
| **Monitor transaction statuses**           | Identifies issues immediately                               |
| **Respond quickly to compliance requests** | Reduces review delays                                       |