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.
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
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 |
