Quote from: Mooshire on September 30, 2013, 04:07:01 AM

Quote from: dezza on September 30, 2013, 03:05:47 AM

I'll give you some idea of how I think the application should be composed (although I've not made one myself, I make that clear).

You need a way to handle the transactions (inputs.io)
https://inputs.io/api
Here's the API to use^

Then you need to program some business logic, that is the glue and requests through the web language of your choice (PHP, Python, Ruby etc.).

You could make the web language frontend request a backend-service, written in another language, or the same language for handling the occassional processing (of scheduled payouts).

I know I keep saying this, but Golang is great for backend services (It's easy multi-threading and the nice minimalistic keyword set is perfect), although I think you should just get your proof of concept code working, and you'll make thoughts about your complete design in the process.

And hey; good idea to get someone to security audit it. You can ask some people kindly, but there is also http://codereview.stackexchange.com/ it's in beta, you might wanna try it.

There's also automated scanners like
http://wapiti.sourceforge.net/
(I think it's still a good one, but others might have come in to the game, this is the one I used last time).

glhf

Heading off now, but if i'm correct, backend services require a VPS, so since I only have shared web hosting i've been looking around. I've found koding (http://koding.com) and was wondering if that was good or bad. I also have absolutely no idea how I would even use anything other than PHP to output HTML or to do backend jobs.

You can always run both frontend and backend on the same servers as on a VPS locally.

Oh I remember you said that, well - The first thing is just getting to learn the inputs.io API, and practise till you feel confident in it. You can try the simple examples on the API page and try modding them.

PHP is fine, just take things one step at a time.