Some thoughts about failed/cancelled payments-

According to the e-gold Shopping Cart Specification 6nov1999
the egold server only sumbits a form directly to the merchant's
web server to indicate payment has been made. Which means the
egold server does not tell you about failures or cancels and
you have to hope the buyer does or check history.

Has consideration gone into providing "Payment Transaction Form"
or equivalent for failed/cancelled transactions? 

It is not uncommon to have the shopping cart or whatever software 
log the purchase as order "pending" before customer leaves
for egold site (and include session info in baggage...) 

So if purchase was successfull
using a md5 calculation the merchant can validate
the integrity of the return on the "Payment Transaction Form" so 
merchant can be sure of a confirmed payment and
the software can change order status from "pending" to "confirmed".
I think it is important if the software is changing status to have
egold server do the confirm and not rely upon customer browser.

Now consider that the purchase was unsuccessfull or cancelled.
The egold server does not send a "Payment Transaction Form" to
confirm unsuccessfull nor to confirm cancelled.  The customer/buyer
should (but now always) follow hyperlink back carrying the
"Buyer Alternate Return Form" 
If the customer comes back they come back
with PAYMENT_BATCH_NUM=="0" and it could have been forged, 
we do not have a handshake_hash nor v2_has to be sure.
we have to trust that no one would purposely forge a failed/cancelled
transaction (would they? can anyone conceive of such a sitituation?).  
Then we have a choice if the buyer comes back to us to change
order status from pending to cancel immediately or maybe throw
up a page saying that order was not completed do you wish to
cancel or retry...
The other possibility is that customer gives up or never
returns from the e-gold site, so now we have a order left in
"pending"s status.  At a minimum a human being or a very very clever
script will have to check egold histories to see why an e-gold
transaction got left pending.  And then make a decision or email/phone
customer and decide to cancel or ask customer to resubmit.

Overall if manpower to contact buyer or more complexity in software for
history check is worth it to make the sale for customers that
bail/fail/cancel at egold then the situation is acceptable.  The
other thing that merchant software could do is to note that all pending
orders that are older than say twenty minutes? have to be dead and either
have/allow human to change status from pending to "failed" or
"canceled" or have timed task, crontab, to expire and change pending to
say "canceled"

I believe that in the majority of transactions an expired "pending" is
just accepted as cancelled for most e-gold merchants.  And in the majority
of transaction a buyers webrowser coming back as "failed or canceled,
paybatchnum=0" would be not questioned as forged.     I can't help
thinking in the back of my mind that their may be a reason to want the
e-gold server to submit directly to the merchant's server if it knew
positively that the order was cancelled... But I'm not sure either... 
...Also to consider having a reply for cancels would increase complexity
on the e-gold sci also and just like taking extra napkins when not needed
a taco bell or throwing away aluminum cans causes waste/inflation
requesting services that are not needed will hurt all of us in the long
run...  

- paul 





---
You are currently subscribed to e-gold-tech as: archive@jab.org
To unsubscribe send a blank email to [EMAIL PROTECTED]

Reply via email to