Goodbye 2016!

In case anyone is wondering if I’m still doing development, the short answer is yes!

The long answer is, not quite! But perhaps this last post for 2016 will shed some light on what’s been happening.

I had a long downtime. I guess I had an early mid-life crisis, because I was still figuring out my life, especially since my personal life is quite a mess. But I had a lot of time to think, thanks to that: Do I really want to make games, or do I just want to dream of making games?

My answer had always been yes, and I would justify it with grandiose goals and noble reasons. But the truth is, I was just chasing a dream. And like most dreams, mine went unfulfilled because I spent so much time fantasising over it, distracting myself in local indie gamedev social circles when instead I should’ve been seriously putting 110% into developing my game.

So 2016 has been a pretty huge year for me. I had hit rock bottom this year, but I won’t bore you with the details. On the bright side, I do think I have a clearer idea of where I want to go from here on.

I’m sure everyone had their fair share of good and bad moments this year. But let’s look forward to next year. Onward to 2017!

Server adventures 5

Continuing my work in NodeJS & Paypal. Payout to customers is pretty straightforward — the documentation’s example was more than enough to get me started and I tested without issues.

paypal-logo

As for credit card payments, I hit a roadblock for a short while because I had to test with fake credit card numbers in the sandbox environment. I copy-pasted the sample code for credit card payment from the examples, but somehow the response JSON gave a “state:created” rather than the expected “state:approved” value. Without the “approved” state, my test merchant account wasn’t getting any money from the test credit card.

A quick google search turns up this link, and it seems like an outdated/deprecated list of test cards. Stack Overflow doesn’t say much either, but after reading through the documentation more thoroughly, I came across this text in this page (under “Test Credit Card payments” section):

  • Note: For sandbox calls, you can use the credit card numbers provided in your sandbox test accounts.

True enough, when you create sandbox accounts, you will find that these accounts will also have credit cards associated with them. Use those instead when testing, and it works — My test merchant account now gets money from the test credit card. Yay!

Server adventures 4

My friend hopes to push for a working demo-able MVP by Wednesday, so I have to pause my other freelance work to crunch on the NodeJS project full-time since last Sunday. I worked on implementing and testing Paypal payment gateway, and finally had the chance to see what Braintree was about.

paypal-logo

To put it briefly in relevant-to-what-I-wanted terms, Braintree is a standardised gateway for receiving payments from clients, regardless of whether they are Paypal or not. If you’re using Paypal API directly, you can only perform actions with their platform.

braintree-logo

I tried using Braintree at first, but later I decided to just use Paypal’s API because I also needed to pay customers (which Braintree doesn’t seem to support at the moment). Since my friend’s startup service requires both receiving and giving payments to customers (think Uber or AirBnB), I had to figure out the API to:

  • Receive payment request
  • Store the invoice for unpaid payment
  • Confirm payment, then update invoice and database
  • After the seller delivers the product and customer confirms it, update product status
  • Add a new invoice for payment from company-to-seller
  • Confirm transfer, then update invoice and database

Here is the gist of how payment gateways work (from what I’ve learned in two days so far):

  • You first tell Paypal you want to “create” a new payment (by the customer), and provide a callback URL (Paypal will use this URL to redirect the user after successful payments)
  • If you configured the “create payment” correctly, Paypal will respond with a payment ID (which I will regard as the invoice ID), along with an “approval URL”.
  • You will then have to redirect the user to Paypal via the “approval URL”, and let the user make a payment securely.
  • Upon successful payment, Paypal will redirect the user to your callback URL (naturally, your website) with the invoice ID.
  • You then use the invoice ID and update your database accordingly, to confirm the product purchase.

It seems Paypal’s documentations have changed drastically, as StackOverflow’s solutions seemed to point to broken links or pages that don’t seem to contain the correct info. Thankfully, the documentation has changed for the better, and seems to be a lot easier to use too.

Next I had to figure out a way to pay customers, but I haven’t gotten to that part yet so I’ll leave it for part 5.