I originally wrote this post on NYC Dev Shop's blog back in March. I've heard this post has helped a couple people trying to integrate their site with Balanced Payments, so I decided to re-post it on Fix It With Code.
I recently got to work with Balanced Payments for an education project, and it was a breath of fresh air after having stumbled through Authorize.net and Paypal. The coolest thing about Balanced Payments is their thorough documentation, and how easy they make it to test that the payment process is actually working. And if you care about more than the coding part - they also have escrow services, and don't have a holding period before you can pay out.
Getting a test account is painless. To get started, visit this page, and you've just signed up in one click. Well, almost. You've got your API key, and if you want to hold on to it longer than the life of the page you're on, remember to click 'Claim Account' in your profile menu before moving further.
Once you've got your own test account, you can start coding.
First, install and configure:
Next, let's build a model that can be responsible for handling all the payment processing. When we create a new payment we'll need to provide an e-mail address to check if the buyer exists, the amount to charge1, and the credit card to be charged. We're also going to add instance variables for a buyer and a card to make some future methods a bit cleaner. And finally an instance variable for an array to store all of our error messages.
Once we've got a new instance, we'll want to check if the buyer exists in our marketplace already, and if he doesn't, we'll want to create his payment profile.
Before we create a buyer though, we'll need to create a new credit card first. Once we have that information, then we can use it to create the buyer if one doesn't already exists.
Looks like we've got all the information needed to charge the buyer, so let's charge him, and include the text we want to appear on his credit card statement.
Now that we've charged the buyer, we can credit the owner's bank account.
Let's make one final method that combines all our individual methods together, so we can have a nice, clean controller later.
Before we can call our payment object complete, let's also add a way to retrieve any errors for the payment in our controller, and for some added security we'll make all the methods that we used to craft that final method private.
Lastly, let's set up our routes, controller, and view so we can test everything out as a user. You'll notice how clean the controller is because of our payment object. And when something goes wrong, you can either show the user all the errors or just the first one. I chose just the first one because it will be the most relevant.
If you need some fake credit cards to test with, you can conveniently visit Balanced Payments testing documentation to simulate a successful credit card, a processor failure, or a tokenizer error.
And that's it. Simple and clean payment processing from an awesome provider. Stay tuned next time when we transfer payments to sellers.
1 If you're passing a dollar amount, make sure to convert the amount to pennies first, so you don't end up accidentally charging $1 when you mean $100.