Integrating payment gateways in Drupal Commerce 2.x is easy!

To say that payment gateways are much improved in Commerce 2.x is a bit of an understatement. The process of implementing a payment gateway has been cut down to about a third of the time, with more functionality rather than less.

How could this be, you ask?

We took a whole bunch of stuff you used to have to custom make for each payment gateway and put it right into Drupal Commerce itself. That’s not as easy as it sounds. You have to make sure it works for every kind of payment gateway out there: regular ones that take credit cards, those that use PayPal or Apple Pay, even those that accept Bitcoin.

We wanted to simplify the process without restricting it—and that’s what we managed to do. (It took three revisions and a lot of time, but hey, Rome wasn’t built in a day.)

Typically, when you implement a payment gateway, there’s some sort of library or API for that gateway, and you need to connect that library to your ecommerce system so that when you want to process a payment, it knows to tell that library to process it. That used to take 20 or 30 hours of work. Now, we have it narrowed down, so you have to write very little custom logic to link things up. It really speeds things up.

Tokenization

We use tokenization for everything by default. Tokenization is when you take a credit card number and you pass it on to the payment gateway, and they give you back a reference for that credit card. So any actions taken on that card (payments, refunds, pre-authorizations) are done against the token and not against the actual card. You don’t store the credit card number; you just store the reference to it.

Tokenization has two big advantages

If that card expires and a new one is issued, most payment gateways will handle that on the back end, and you just use the same token you always used. This is how Netflix is able to keep right on billing you for eternity; they don’t need your new credit card. (Unless you cancel it and get an entirely new one, of course.)
You are not storing the credit card number, which is good for PCI compliance. The more modern gateways like Stripe and Braintree have a JavaScript layer so that you don’t store that credit card number even for a fraction of a second; it never touches your server. It goes right from the user’s browser to the payment gateway, and the gateway delivers the token. So if you get hacked, you don’t compromise those credit card numbers, because you never had them.

Multi-currency

We use a localization library provided by Google to handle pretty much every kind of currency in use in the world. This is important because you have to know how to format the numbers: What symbol does it use? Does it have decimal points? Does the currency use commas or periods as separators?

Even the language the currency is being displayed in will affect how it appears. Take the Canadian dollar, for instance. In English, the Canadian dollar has the dollar sign at the beginning and uses a period as the decimal separator; in French, the dollar sign goes at the end, and the separator is a comma.

The bottom line

In Commerce 2.x, implementing payment gateways is a lot simpler, and there’s a whole lot more functionality.