Features that have ramifications beyond the direct experience with the software

Question

This isn't so much a "how do I do this" question as it is a "real world ramifications of a design decision" question.

I noticed today that, when using Google Wallet for a payment, when one goes to pay for the service it is possible to see a payment method option as disabled and flagged as "declined" even before choosing that method.

A useful feature, to be sure, but I worry about the ramifications of this from the perspective of the systems on my bank's end.

I can only assume that this is implemented by simply pre-authorizing the payment on each saved account prior to showing me my options.

For those of you who have written banking software, do you know of any specific effects this feature my have on a user's account? What about the potential effects on this system as a whole?

Also, I'm sure that since the release of this product (or at least this specific feature), the feature itself has almost certainly created an additional load on the "middle man" systems in this scenario that may not otherwise be there.

Ultimately, this is my question: Is adding a feature that can have ramifications beyond the direct experience with the software really a good design decision?

Answer 1

This is standard practice in the banking industry for such transactions. It is called an authorization hold. You are most likely to notice an authorization hold when staying at a hotel. Hotels usually put an authorization hold on your credit card for incidental purchases such as room service or purchases from the in-room minibar.

There are a handful of issues that could happen to the user's account as the result of an authorization hold. If your hotel stay is lengthy, the authorization hold could be placed on one billing cycle, but the actual charge to your account could be placed in the next billing cycle. This is problematic if the user's balance is close to their credit limit. Another issue is the difference between the held amount and the actual purchase amount. This is most frequently observed at gas stations where you pay at the pump, and in restaurants where you might add a tip to the total bill.

The benefits of an authorization hold are significant. For the end-user, being declined for an authorization hold does not count as going over their credit limit. Going over the credit limit potentially has impacts to the credit score. Being near the limit can alert the end-user that another issue has occurred, such as a payment not going through or a stolen credit card. For the merchant, they can quickly check to ensure that the buyer can actually buy what they want to. This shields them from problems such as a stolen credit card or a buyer who is over their credit limit.

The banking system processes millions of payments per second, and their databases are designed for transactions just like this. Authorization holds are quite common, and thus there is no additional load to the system by showing you that an authorization hold has occurred.

This is a good example of a design that does have potential ramifications outside of the specific interaction that the user is engaging in, and that has addressed the vast majority of these issues in favor of doing something that has significant benefits to both the user and to the merchant. The banking system has had decades to perfect transactions to minimize disruption to the end user as well as disruption to merchants and credit-card processing companies.