So no update yesterday. I blame the Majewski Afternoon Time-Barrier Principle. Let me explain. You may – perhaps even without knowing – be familiar with the Novikov self-consistency principle. It’s a theoretical model of how time travel could be possible without creating paradoxes. According to this principle, all time travels have already happened. So if you go back in time and try to change anything, something unexpected will happen to prevent you from making the change. As if the universe defends it’s own consistency. A good example of said principle in action is shown in the movie 12 Monkeys.
The Majewski Afternoon Time-Barrier Principle states that for every day you have at your disposal to work on a creative project, you physically won’t be able to begin before 5PM. The universe will prevent you will all it’s might to stop you. Perhaps you will have to do some overdue groceries, clean the flat or you will oversleep or even receive a really distracting Amazon shipment. The Majewski Afternoon Time-Barrier Principle is the reason why I always have been working at night. But that workaround stops working so well when you get a dayjob.
Back to serious. I have been setting up the payment system for the TRAUMA website. It is finally coming together. A small problem caused some headaches. Last weekend I have been trying to generate a direct payment by tapping into the instant payment button HTML form using PHP. This is a bit out of the ordinary. Usually, one would use the PayPal PHP SDK. But I don’t have the nerve to dive into it. It seems to be made for people who like to toy around with shopping baskets. I just want a plain direct payment with perhaps a bit of control.
I finally figured out that it’s basically not possible. The workaround everybody uses is to generate an HTML form with PHP and send it with Java Script. Duh! Not very elegant either. But it will have to do for now. I will post a detailed walktrough when I’m finished.
During further tests, I stumbled across an intriguing idea. You see, every time I test my system, I have to make an actual payment of 1 EUR. This is how my account looks like.
And you thought waiting for code to compile was nasty?
On the one hand, it makes bugs super-annoying because you actually have to pay for them with real money. The process is also a pain to debug as the code you write isn’t executed by yourself. So you can’t really trace out error messages and whatnot. On the other hand, I have never written so clean code in PHP. In 9 tries from 0 to first payment went trough flawlessly – that’s certainly a personal best. Perhaps I should adapt this system for other areas as well.
Of course, I’m making the payments to myself. So I will get some of that money back. But not all of it. Especially at this low ammounts, PayPal keeps a hefty percentage. It’s really quite sad. I would have loved to experiment with Micropayments.
So all in all, I’m on track. Will continue working on the payment system and release it for other Indies to adapt. Most of it should be done next weekend.
Not to discourage you, but is it really worth the hassle to make a custom payment system over just using Fastspring/BMT Micro, or the like? With all the hassles with sales tax a custom system is gonna cause, I can’t imagine it’s really worth it…
Also, I am very very excited about playing the final version of Trauma, finally
Thanks Terry! I hope you have been enjoying you pint of cider today.
Sales taxes should be handled by PayPal. Maybe I’m missing something crucial but there is very little the payment processing systems do. They just get in the way of creating a really streamlined experience. I have been working on this game for so long now, one week won’t make much difference.
Well, if you’re sure! My understanding of it is when somebody buys something online, they’re supposed to pay their own county’s local VAT, or whatever. They pay it to you, then you pay it to the government in question. The real benefit of Fastspring and the like is that they take care of all that.
(But maybe I’m totally wrong, Minecraft just uses paypal as far as I see…)
You can use the PayPal sandbox to test each and every thing PayPal might throw at you – it is invaluable for when you start doing IPN’s.
Tax laws on non-physical items are unclear – they are to me, to advisors, even sometimes to the government itself. It is best to call the tax helpline and ask what they expect of you. And just to note – you may have to prepare yourself to explain how software may be sold on-line and how exactly you use PayPal.
as far as i understood it (and of course there is a high chance im wrong)… actually the tax stuff is rather easy – and complicated at once:
i tell you a price (whereever you live, whereever i live), you pay it.
thats it. really.
the problems come, when you and or me want to avoid paying more taxes then necessary:
-if the buyer wants to reduce his payed taxes for products which he may deduct (right english word?) from taxes, he has to prove / tell the tax on that product. this is only possible if i tell you the tax value on my product, and i pay the taxes to your state. so if i’m a german and you are, its easy. its just 19% tax on (basically) everything. so even if i do not tell you that it is included in the price, it actually is (because i have to pay). if we do not live in the same tax system (i.e. you in the US and me in the EU) then you simply cant deduce the taxes (AFAIK).
-for me as a seller (AFAIC im writing about my knowledge of european tax, which should be similar for all EU countries and probably not far from US/asian tax systems) if i only sell very small amounts (of money, not products) the money can be counted / paid taxes for just like the money i would get as an employed worker. if i want to reduce my taxes on that (i.e. do the same from the above example, just with the things i bought) i simply can (with 19% in germany).
-if i as a seller sell more than a small amount (thats typically a yearly sum) i have to pay (upfront) extra taxes (umsatzsteuer in german, IDK what that is in british/american english). now i can go the simple way and just keep my price at it is and pay my taxes (lowering the amount of money i can keep later) or i can charge my customers for the taxes, by explicitly telling that the product now has additional umsatzsteuer and go for a higher price.
kryst:
i can’t imagine that you actually have to test with real payments.
everybody needs to test his system, and everybody paying real money for that? people would be outraged.
there must be a test server / mode for that!
you must’ve missed that!
Oh yeah. Like Jeroen said there is a “sandbox mode”. I found the sandbox setup mind-bendingly complicated. You have to create separate sandbox accounts for a fake seller and a fake customer. Each with it’s own email and password. You have to log in to each one of them and fake-authenticate them. And even then, the scripts for the sandbox servers actually use different URLs. So moving from testing to release would be another potential source for bugs. So I decided to use the force and turn off the targeting computer. But if it gets too difficult I can still go sandbox. Luckily, it looks like I won’t have to.