Do not wait for an end-of-day report or customer complaint to discover a decline in payment success. MagicPay Payment Monitoring and Logs tracks current transaction outcomes and error trends across connected acquiring services. Receive notifications when the success rate falls below your configured threshold or a defined error condition occurs, and investigate where a transaction stopped through a shared timeline. Success rate monitoring and an individual payment's technical history become part of the same operation. Support, finance and engineering can use order and provider references to reach the same sequence of events instead of exchanging disconnected log extracts.
Read success rates at the right level
An overall rate may not reveal the source of a problem. Review breakdowns by bank, card type, card program and sales channel to identify the affected transaction group. Evaluate initiated payments alongside completed outcomes for the selected period. Return to the transaction history without confusing retries with separate sales, and investigate how the change relates to provider and routing decisions.
Set thresholds and receive notifications
Define notification rules for falling success rates, increased technical errors and unresponsive acquiring connections. Choose thresholds and monitoring intervals that fit your business to identify events requiring operational attention. Move from the notification to the relevant connection and transaction records. Teams assess the impact using the same data and link the next action to routing and outage management.
Follow each payment's sequence of events
Requests, provider responses, error codes and subsequent notifications are linked to the same payment record with timestamps. When an order remains pending, review earlier steps rather than just the latest message. Delayed outcomes and repeated notifications remain connected to the original transaction.
- Transaction search by order and provider reference
- A shared timeline for requests, responses and notifications
- Combined investigation of error codes and status queries
- Access to retry and alternative route history
The data needed for investigation, with controlled access
Sensitive fields such as card numbers are masked; investigation views use the information needed for technical analysis. Security codes are not included in support messages or shared logs. User access is limited according to responsibilities, while masking, access and retention rules are managed as part of operations. Investigating a problem does not require circulating customer card data between teams.
Turn data into routing and provider decisions
Investigate which errors recur in each card group and how outcomes evolve after rule changes. Engineering investigates connectivity, operations follows alternative routes and finance tracks the related payment outcome. Build a shared basis for investigation across multi-acquirer online stores, platforms and dealer collection teams, and use the event history in bank discussions.
Monitoring and investigation in three steps
Move from overall payment health to individual transaction details through the same reference chain.
- 1. Connect acquiring, channel and transaction outcomes to the shared monitoring view.
- 2. Define notification rules for success rates, errors and connection health.
- 3. Move from a notification to the relevant transaction timeline and track the outcome and action taken.