When a phone accepts payments, protection decisions affect sales continuity. Blocking a new transaction and obtaining the result of an existing payment are different flows.
Evaluation approach
Separate registration, initiation, approval and status queries. Define where operations stop when risk changes. Use unique transaction identifiers so retries do not duplicate charges.
Application example
A suspicious merchant device may be prevented from starting new payments while retaining a safe route to check a payment already submitted. Simply closing the application can leave a sale unresolved.
Limits and considerations
A RASP product alone does not complete MPoC assessment. Solution components, monitoring and operations need their own evaluation.
Checks and decisions
- Document the payment state machine
- Make retries idempotent
- Give support the transaction identifier
Test safe status retrieval alongside safe rejection, with the sales workflow in mind.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.