-3

The company I work for processes donations for non-profit clients. We recently ran through a patch of problems which caused us to lose donations due to bugs either from our system or the vendor actually charging the money.

In the past, this just meant the donor saw an error page and we hoped they would resubmit the form when things were working. My team was moved off of that project and new engineers have since been enhancing it, but I remain on our support team for payment processing.

Since I stopped actively developing the product, the company is working with TokenEx to tokenize a donor's payment information "as a layer of resiliency", as is described on our client-facing documentation. Someone recently explained to me that this means that when we have a bug or one of our vendors has a bug, we now have the ability to "replay" the transaction when we know the issue is cleared up so that our clients don't miss out on money they should have made. This doesn't sit right with me and is where my first ethical concern is:

Is it okay to replay a transaction at a later time on behalf of a donor when things go wrong the first time on the grounds that "they intended to donate that money"?

To make this feature even more sticky, I heard of an emergency switch we implemented called "success only mode" which doesn't even attempt to process the transaction. Instead it tokenizes the payment information and shows the donor a message saying "we are processing your payment". When we know things are good, we pump all of the stored tokens into our processor in hopes of having the highest possible success rate. This is my second ethical concern:

Is it okay to store a donor's payment information knowing full well that you plan on waiting to process the transaction until everything is working, to the best of your knowledge?

It is important for me to hear objective opinions on this because I'm on the support team for this app and, while it hasn't happened yet, I am worried that I will be asked to carry out one of these two processes in support of the app and I don't know if I feel comfortable doing either of them.

I believe that, as a payment processor, it is my job to attempt to process a payment at the moment that the donor intended to make the payment and, if I am unable to successful complete the transaction, neither I nor my clients are "entitled" to the funds despite the donors initial intentions.

Here's a contrived example of why I think my opinion holds up. Suppose your mother wanted to give you $20 for "being a good kid". She drives to your house and knocks on your door, but you're not home. So she goes to the market and buys some groceries with that $20.

Now imagine that you had a security camera installed and you knew she came with the intent to give you that $20. Would you go to your mother's house, knock on the door, and say "I'm here to collect that $20 you stopped by to give me earlier" and when she says, "Well, I spent it already because you weren't home" would you feel like you have the right to say "You originally intended to give that money to me so I am here to collect what is mine"? I wouldn't, and for that same reason I can't justify hiding our failures behind TokenEx and "success only mode".

  • 4
    It doesn't seem too much different from an on-line vendor sending me an instant order confirmation email, but not charging my credit card until a few hours (or days) later when they confirm the goods are available and start the shipping process. – Laconic Droid Jul 20 '18 at 16:03
  • 1
    These sound like questions that will be highly subject to local laws, and I don't think we can answer them here. I suggest you talk to your company's lawyers about the situation. – David K Jul 20 '18 at 16:13
  • Does the customer receive order confirmation or do they just get an error page? Ideally this is something that should be hashed out with a lawyer. – user1666620 Jul 20 '18 at 16:13
  • @DavidK, he's asking about ethics, not legality. – user1602 Jul 20 '18 at 16:19
  • 3
    Mastercard and Visa maintain documents outlining their rules for processing transactions, you could read through those if you have some time and want a thorough understanding of what's acceptable behavior. – Sam Dufel Jul 20 '18 at 18:01
8

That example is...quite contrived indeed. How about a different contrived example:

Your mother stops by to give you $20. She writes you a check and slips it into your mailbox slot. You get home but can't find your mailbox key. So the $20 sits there for a week until you finally find the key.

Can you now cash or deposit the check, or do you need to check with your mother to see whether she still intends to give you the $20?

In the words of Joel Spolsky:

The moral of the story is that with a contrived example, you can prove anything.

Now to answer your questions...

Is it okay to replay a transaction at a later time on behalf of a donor when things go wrong the first time on the grounds that "they intended to donate that money"?

Yes...IF. If you know the problem was due to a technical glitch on your end, and that the payment didn't go through, then you're just remedying the technical glitch.

But you need to know those things. If you got a donation on a debit card, and it didn't go through due to an insufficient balance, the owner might get dinged with, say, a $20 insufficient funds fee. If you try to process the donation again, you might cause them to get hit with another $20 fee.

Is it okay to store a donor's payment information knowing full well that you plan on waiting to process the transaction until everything is working, to the best of your knowledge?

If you're using tokenization, you're storing their information, yes, but safely, in a form that no one but your organization can use. That's the whole point of tokenization; even if somebody stole all the tokens, they can't use them, because they're not your organization.

So yes, this is fine, on the same grounds as the previous one: The payments can't go through (till later) due to a technical glitch on your end.

(This answer is only intended to answer the ethics of the situation, and not the legality.)

  • 2
    The OP says that the users saw an error page if the transaction failed. If the user is told that there was an error, then it would be reasonable for them to conclude that they would not be charged. – David K Jul 20 '18 at 16:41
  • @DavidK, did you see the part where the OP said "in the past", indicating that they don't plan to do it that way anymore? – user1602 Jul 20 '18 at 16:44
  • Yes, I saw that, and the OP did not indicate either way whether an error screen will appear for the user in the future or not. Regardless of whether you agree with that or not, it would be worthwhile to explain the ethics in a situation where an error was given to the user. – David K Jul 20 '18 at 16:50
0

To make this feature even more sticky, I heard of an emergency switch we implemented called "success only mode" which doesn't even attempt to process the transaction. Instead it tokenizes the payment information and shows the donor a message saying "we are processing your payment". When we know things are good, we pump all of the stored tokens into our processor in hopes of having the highest possible success rate.

I re-read the OP and understand it slightly different now. The OP is stating that there is a "fail safe" logic in place when the credit card processor is failing. The logic normally processes payment right away but occasionally the processor will fail so the fail safe design is to make it appear the transaction went through, but it is building a "token" queue for a backend processor and push it through later. That doesn't sound unethical to me if it is within a reasonable time frame (a week or so). The concern is that the customer is having a buyer's remorse and might not intend to donate anymore. I don't see how that is unless you're leaving out some additional steps like the customer seeing an error page and thinking their transaction didn't go through at all and later getting a surprise. So long as the customer understands there is going to be a charge and that your company confirms this, I don't see any issue with having a fail safe in place.

A good example of this might be where your grandma writes you a check for $20 dollars and you made a eDeposit with your mobile bank app. Later, your house burns down along with the check. Does that mean you have to ask grandma if she still intends to donate the money to you even though your bank is still processing it but the check is burnt up? Probably so since your grandma gave you the money with the intention that you have it regardless of how you process the payment. That is the same intent with your donation: you are attempting to process the transaction but the original transaction failed (aka "burnt") but the customer still intends to donate in the original transaction and you're processing it later as a fail safe.

Not the answer you're looking for? Browse other questions tagged or ask your own question.