Hi Folks,
It seems that a Customer made a purchase that now requires a refund. However, the Customer has changed the credit card number associated with the Payment Token since the purchase. There is only one payment token and it now has the new credit card, which is rejected for the refund transaction. I undersand that.
But....What to do?
While writing this email, a wave of realization is descending upon me that makes me think that this is what multiple payment tokens are for: Detect whether an edited CC number is different and then create a new Payment Token, versus if the edit is simply to update the Exp Date and using the existing Payment Token.
Anyone?
Jonathan
Solved! Go to Solution.
01-15-2013 02:42 PM - edited 01-15-2013 02:54 PM
We save the last 4 and the transactionID for each transaction. That is enough for a refund transaction, you can use either AIM or CIM, but it probably easier with AIM.
01-15-2013 04:40 PM
OK. I've had some time to go through all the options and I ended up manually refunding the said purchase on the Auth.net site.
But I guess that I'm looking for confirmation that creating and storing multiple Payment Tokens is the ultimate answer to avoid this problem in the future. I never thought of needing this until this incident. Is this a common practice?
Thanks
01-15-2013 03:42 PM
We save the last 4 and the transactionID for each transaction. That is enough for a refund transaction, you can use either AIM or CIM, but it probably easier with AIM.
01-15-2013 04:40 PM