- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I'm sure this is not the frist time this has happened.
Admin
I'm sure this is not the frist time this has happened.
Admin
Hard to be certain without looking at the whole code, but surely the payment request has gone off and may have returned a 200? Has payment been made at that point?
Could be that the payment is succeeding, and the app is just saying it failed. At which point the punter might try it again (maybe more than once).
Could be that this is going to reduce revenue....
Admin
I imagine it will decrease the number of chargebacks a bit.
Admin
Presumably, in the case of timeouts and other net-related failures, an exception will be thrown?
Admin
His "new" solution is just as bad, really. What's with an unexpected HTTP-code like 301 "moved permanently"? Or something like 208 - "Already reported"? Or even ANYTHING else? (timeout, etc...)
Admin
It's less bad, it's not equally bad. His new solution succeeds some of the time, which is more than none of the time, even if it's not the vast majority of time.
Admin
Usually payment processors return a transaction ID or token.
Then after the transaction has completed, the payment processor will request a url you specify in their admin and send the token to validate. You check the request's referrer, you check the token matches, and then you run payment callback.
Then it's decoupled. Sending a payment request, and running code on successful payment requests are separate do not depend on one another. You can add reporting and alerts if a payment was sent and never validated, or validation is being attempted without payment.
Of course you shouldn't be sending credit card info over a network on an app. That will land you in prison.
Admin
We're talking mobile games right.
I work with payment providers on daily basis. I can't really remember the last time a provider as Paypal or Credit card services decided to change their fucking API to redirect to a different URL. Do you really think that would ever happen? If this was not made up, that would totally be fine for checking for an error response.
Admin
Actually aren't most mobile games using in-app purchases against the platform store (Apple or Google predominantly) so the game company isn't actually doing the charges, they are only collecting their 70% every week or whatever. So a simple check of success seems fine.
Admin
That's not how it works with typical in-app purchases using iOS's StoreKit and Android's in-app billing libraries. There's no requirement for an additional validation step — in the simplest case, you make a request to the API to purchase a particular item, and shortly thereafter you get a callback on whether or not the purchase succeeded. Once it succeeds, the user has been charged, and unless they dispute it through Apple/Google/credit card issuer, the charge will stick.
So if the application code crashes or otherwise ignores a successful purchase response, the user will not get the goods they paid for.
Admin
Thank you.... right you are. It is cringeworthy how condescendingly the author of this article criticizes code without actually understanding that it is perfectly valid.
Admin
It's not that simple. In case of the App Store, Apple tells the app that a payment has been made. The app should deliver goods to the customer and then tell Apple that the payment has been processed. If it doesn't do that last step, due to a crash, or network failure etc., Apple will tell the app the next time it is started that a payment has been made. So the user will only ever lose it if the app tells Apple that goods were delivered, without delivering them. But in that case the user will complain to Apple, and get their money back. Which is bad for the seller, because Apple keeps their 30% processing fee, but returns 100% of the payment.