Today e-commerce platforms are essential for companies selling their products and services online. One of the critical functionalities of any e-commerce platform is payment processing. But with the rise of cyber threats and online fraud, these platforms must provide the highest security standards to protect their customers’ sensitive financial information.
At the same time, the online payment flow needs to be designed simply and efficiently for all customers, regardless of their level of computer experience. This way, e-commerce platforms can ensure a seamless and user-friendly payment process, leading to higher customer satisfaction and repeat business. In this article, we’ll dive deeper into the importance of processing payment and explore some best practices for achieving it.
How does payment integration work in Ruby on Rails?
There are several approaches to how the payment process can be triggered in the app. One direction could be to enter the payment details directly in your app and transmit them (securely) to the payment provider.
Another method is to take the user to the payment provider’s website (or display a pop-up or iframe), where the user enters the payment method of choice and then enters the relevant data. Many users may feel more confident entering their credit card details on a well-known payment provider’s website, so this is worth considering.
After providing card details (or logging into your bank account), a payment provider authenticates this information and confirms the payment by contacting a payment processor. The payment processor communicates with the bank to settle charges.
Using this flow, your application’s backend does not store sensitive data – it’s your payment gateway’s responsibility. If you want to save a user’s payment method for later, you only keep a token representing that method.
How to choose a payment gateway?
Available payment models and methods
Before looking for a suitable provider, decide which payment model you want to implement. There are several different approaches, significantly different from each other, and it is worth remembering that not every provider will support every method.
This is the typical flow when the user selects the product/products and then goes to the payment process, where he chooses the payment method that suits him. The checkout form can offer many different payment methods:
- bank transfer,
- BLIK (a prevalent and convenient method of payment in Poland),
- debit/credit card,
- Google Pay / Apple Pay,
- pay later.
From a technical point of view, the usual flow looks like that:
- The user clicks the pay button.
- The front-end part of the application communicates with the Back End and obtains the payment link, to which it redirects the user.
- The user is redirected to the payment gateway’s page when providing payment details.
- The payment gateway processes the payment and sends a webhook to your backend with the status.
- The payment gateway redirects the user back to the store page.
You will be interested in this method if you want to charge the user recurring payment, such as access to some service. The subscription period is usually one week, month, or year.
This form of payment requires credit card details, which will then be charged. Some providers also support Apple Pay / Google Pay.
There are a few things you need to keep in mind when dealing with subscriptions:
- Support for Strong Customer Authentication (SCA) – verify if your payment gateway provides good support for this regulation. For subscriptions, the first charge of a fixed amount with a fixed interval would need to go through 3D Secure. If the amount changes or there is an upgrade in subscription, it will likely need to go through 3D Secure again
- In-app subscriptions – when you implement subscriptions within the mobile app, verify that you do not need to use Apple Pay or Google Pay subscription (15- 30% commission)
If you sell digital goods, you cannot use an external provider.
- Using trial periods on subscriptions is an advantageous way to encourage users to check out your paid services. You need to consider whether you already want to collect payment data from the user at the start of the trial period or only after it has ended. This is likely to affect conversions, and A/B testing may be necessary. Also, check what options your payment provider offers.
Merchant Initiated transactions
There are many use cases when you might need this type of method
- Delayed charges – service is provided now but will be paid after the user has finished utilizing the service (for example, when you rent a car and pay for the number of kilometers when you return it)
- Penalty charges – when the user fails to comply with the regulations and will be charged for it
- Installment payments – when the user selects the option `Buy now, pay later’ – e.g., in Airbnb, where you can pay half at the time of booking and the other half a few days before your stay at the hotel.
Ease of implementation
You need to verify if your payment gateway provider provides a dedicated library for Ruby on Rails. If they don’t have dedicated official libraries, it’s worth checking for unofficial versions built by the community on GitHub. However, I suggest you use an unofficial library. In that case, it’s worth verifying their implementation’s quality and validity – it may turn out that they are based on the provider’s API, which will soon be deprecated.
Below, you can find a couple of providers that have excellent Ruby on Rails support:
Stripe payment offers extensive documentation dedicated to the Ruby language and an official library which is helpful when you integrate Stripe. At Applover, we have used this integration many times and can confirm that the integration is straightforward. Moreover, Stripe’s support is very responsive and will be happy to help you solve your problems or address your concerns. According to RubyGems, the library has been downloaded almost 50 million times.
Braintree also provides the official Ruby library on their Github. It is actively maintained, and there are only two active issues on GitHub (there are over 100 closed). There is also technical documentation dedicated to the Ruby language. According to RubyGems, the library has been downloaded over 15 million times.
Adyen delivers quite a comprehensive library that supports APIs under many of its services. From the commit history, you can see that it is actively maintained. They also provide:
According to RubyGems, the library has been downloaded almost 1 million times.
There are also many unofficial libraries for other payment gateways created by the Ruby community. Unfortunately, many are not actively used, but they can be used as inspiration/help in implementation.
This is an essential factor in choosing the right payment provider. The price lists of different payment providers are often contracted in different ways, and each business’s profitability can vary. Typical models for charging commissions are a percentage of the transaction or a percentage of the transaction + a fixed amount.
In addition, some operators offer additional services, such as:
- checkout page on a custom domain,
- customer’s identity verification,
- the tax calculation for different countries,
Helpful Ruby on Rails libraries for working with payments
In addition to libraries dedicated to specific payment providers, there are several others with a broader Rails application:
Dealing with money in the application requires attention. You can quickly get into trouble if, for example, you use the wrong data type in the database column that stores money value. If you work with SQL, you can go with INTEGERS or DECIMAL type with a precision of 8 and a scale of 2.
So, what exactly does this additional gem offer us? money-rails is just Ruby gem money formatted to Rails. The main features are:
- provides Money class containing relevant information regarding currency, including its value, denomination, and decimal notation,
- Money::Currency class that encapsulates details about the currency,
- represents money values as integers – floating point rounding errors are prevented by this,
- provides APIs for currency exchange.
It’s part of a `money-rails` gem, useful when you want to convert a different Ruby object (like String) into Money. Example usage:
Monetize.parse("GBP 100") == Money.new(100, "GBP") Monetize.assume_from_symbol = true Monetize.parse("£100") == Money.new(100, "GBP")
This library seeks to provide a consistent interface for different payment providers. At this moment supports the following providers:
- Fake Processor (useful for free trials without cards, free subscriptions, etc.).
However, the owner is open to new integrations and invites contributors to collaboration. This gem might be helpful if, for some reason, you are considering supporting different payment providers.
Would you like to discuss payment integration into your application?
Optimizing your e-commerce experience
In conclusion, the world of e-commerce has grown exponentially over the past few years, and it continues to do so at an impressive pace. As more businesses shift to online platforms, keeping up with the latest trends and technologies is essential to provide customers with the best possible experience. This means investing in user-friendly interfaces, optimizing mobile responsiveness, offering a wide range of payment options, and ensuring the highest levels of security for all transactions. At Applover, we are committed to helping businesses achieve these goals through our expertise in developing cutting-edge e-commerce solutions. By following these best practices and staying ahead of the curve, e-commerce businesses can thrive in a highly competitive market and build long-lasting customer relationships.