Application for Contact Payment Search
Sending money to the correct person among several similarly named contacts requires a verification step the payment infrastructure does not require.
Application submitted by: the person paying.
Purpose: to transfer funds to a specific individual whose contact entry closely resembles one or more other entries in the same contact list.
Supporting documentation: prior experience in which two contacts shared a first name and the payment was sent to the wrong one before the confirmation screen was checked.
Contact payment search adds one extra confirmation check. The check involves scrolling past the first result for a common name to verify that the selected contact is the intended recipient. This takes between five and fifteen seconds depending on how many contacts share the relevant name. The check is performed before entering the amount, then again before entering the PIN.
The payment is faster than cash while certainty arrives through extra checks. The application is being filed in recognition of this gap. Cash required counting and visual confirmation of notes. Phone payment requires certainty about a contact name and a displayed number, which are both available but require deliberate inspection rather than passive receipt.
Both parties start waiting for visible proof. The receiving party in the subject's transactions has started sending a message that reads as confirmation after the money arrives. The sending party screenshots the transaction. These are voluntary additions to a transaction that is complete without them. A fast payment develops a ceremony around certainty.
Under the governing rule, contact payment search becomes procedure once the confirmation check has been performed three times before sending to the same contact. At that point, the check is no longer a safeguard against a specific error. It is the process.
The application requests formal recognition of contact payment search as a legitimate consumer behavior rather than a failure of trust in the payment system. The payment system has not failed. The behavior is a response to the design of a contact list that does not prevent disambiguation problems from occurring at the payment stage.
Application status: pending review. Resolution not expected this cycle.