Implementing Stripe in Ruby on Rails - PayPal Comparison

Stripe might not have the widest reach in terms of the number of countries, but with all the other characteristics it stands out against the competition. It also offers an excellent omni-channel payment experience with a smooth user onboarding. PayPal still holds 75 percent of the market, but with Stripe’s growing popularity, it’s worth considering the latter. It might not be as well-known as PayPal, but outstrips it in many respects.

Stripe in a Nutshell

Stripe is one of the most innovative online payment providers and the second leading company in the industry, just behind PayPal. It focuses primarily on code design to give developers space for building great apps and, as a result, give users a better experience. In addition, it is very secure, because no sensitive data hits your servers. Finally, its implementation with Ruby on Rails is fast and simple. There is a ready object-oriented and well-designed gem supporting Stripe, with complete documentation and easy testing options. It’s a massive advantage for developers – it saves much work and reduces the numbers of lines of code that need to be written. On top of that, it’s easy to verify the payment integration with Stripe’s test API tokens and test card numbers.

Stripe’s Main Benefits:

1. Innovative payment processor

2. Safe, secure and fast payments

3. Easy-to-use and object-oriented gem implementation

4. Complete documentation for gem

5. Easy testing

6. Friendly Interface

Stripe is a Great Solution for Startups

Stripe outperforms other payment solutions when it comes to the speed of deployment and building, making it a great fit for startups. Thanks to simple and composable APIs you can quickly integrate Stripe with your application and start accepting payments in a few minutes. In addition, you don’t have to worry about storing credit card numbers or PCI compliance. Sensitive data never hit your servers making the whole payment process secure. Stripe offers Pre-filled SAQs, which takes away all the hassle from the administrative stuff.

Stripe also provides recurring billing even for the most complex subscription models. You can link your customers to pre-defined plans, and Stripe will do the math for you, billing your customers daily, weekly, monthly, or according to the criteria you specify. It’s possible to add multiple subscriptions to a single customer simultaneously. These features are especially useful for SaaS and marketplace business models.

If you are looking to expand globally, Stripe offers a service that can help you start a global business from any place in the world. Stripe Atlas incorporates your company in Delaware, USA, then they help you open a Silicon Valley Bank account so that you can charge customers globally.

The user experience with Stripe is also as smooth as it gets. A customer only needs to add their card details and click OK, and money is transferred into your account. PayPal, on the other hand, requires a user to sign up and link a credit card to the account, making it more problematic for a user.

Stripe has even more to offer, for instance, Stripe Relay. Stripe Relay is a buy button that you can embed in other services such as Twitter, ShopStyle, InMobi and Spring. Last but not least, Stripe boasts an exceptional user interface. Unlike PayPal, Stripe is intuitive and transparent, making it very easy to find anything you need.

See also: Ruby on Rails in Ecommerce

Implementing Stripe in Ruby on Rails

Stripe’s implementation in RoR is simple and doesn’t require much work from developers. We’ve used it in many projects, and it’s always been an effortless process. From our perspective, Stripe is designed to meet expectations of all groups that use it: developers, app owners and users. What are the main advantages?

1. Quick implementation with a ready gem

The Stripe Ruby gem provides convenient access to a wide range of versions of the Stripe API from applications written in the Ruby language. It includes a pre-defined set of classes for API resources that initialise themselves dynamically from API responses, which makes it compatible with a wide range of versions of the Stripe API. Having an official gem always speeds things up.

2. Additional gem features

The library also provides an easy configuration path for fast setup and use, helpers for pagination, tracking of "fresh" values in API resources, or built-in mechanisms for the serialisation of parameters according to the requirements of Stripe's API. Additionally, there are also automatic retries that ensure that the same request is not processed twice.

3. Well-written gem

The gem for Stripe payments is object-oriented, well-designed, and simple to use. It’s continuously maintained by Stripe to guarantee its compliance with the latest updates. On top of that, the big community of active users and contributors ensure that potential problems are spotted early.

4. Well-documented gem

If you have ever wondered what good documentation should look like, here’s one good example and here’s another. We can easily say that there is no other payment service with as good documentation as Stripe’s.

5. Easy testing in our RoR environment

Testing Stripe in the RoR environment was also interesting. First of all, we could actually test the integration automatically, which is not always the case with payment providers. We used the standard Rspec library and, additionally, the VCR library, which enabled us to automatically test any integration, making it more efficient and reliable.

However, this is only the general-case option that requires catching the one-off tokens with a debugger. Instead, you can use mock Stripe instances such as stripe-ruby-mock, fake_stripe, or stripe-mock, which has been recently kicked off by the Stripe team. While configuring the test environment to use stripe-mock, we can benefit from the gem’s configurability and do it with one line. It is not frequent to have so many good options to test an integration with a third-party service.

We don’t see any drawbacks from developers’ perspective. Stripe is the most developer-friendly payment solution we’ve ever worked with.

Quick tips for Implementing Stripe in RoR

When implementing Stripe in RoR, you should first pay attention to error handling so that you can display the right kind of error to the final user. This will improve UX and is crucial for making the payment successful. Another thing to consider is the difference between building one-off payments and building subscription payments. They require different service flows. In the case of a standard single payment, it can be accomplished in a synchronous manner. It doesn’t take much time and a client waits up to a couple of seconds for the payment to get processed. With a recurring payment, you first execute an initial transaction, and then you need to wait for the Stripe server to respond. Therefore, while a user waits for the payment to proceed, he or she should be presented with a screen containing information such as “Please wait. Your payment is being processed” or similar. Finally, remember about testing, as this part of application involves money.

Testing payments as a part of development

Testing is an important part of development, and testing integrations with any third-party service has its tricky parts: the Internet connection may fail, APIs often have rate limits, and relying on external service makes tests dependent on external factors, which may result in random fails and slow tests. However, the real obstacle is that calling the API actually produces real effects when it should, but in the case of testing, we don’t want to leave any traces behind. In other words, in the context of payments, we don’t want to pay real money every time a CI server runs our test suite.

On the one hand, to test the code on our application’s side, we can deal with these hindrances by using stubbing and mocking techniques. This is where libraries such as Rspec and VCR come in handy. On the other hand, whether it is easy and reliable or not depends on the integrated service’s architecture and its testing capabilities. Finally, end-to-end testing is possible only if the service has some test mode implemented. Stripe stands out in this area.

Stripe offers test API tokens that let us verify the whole integration - payments are processed without transferring any money. The important part is that the payment server stays the same, and everything works just like with the real tokens.

Additionally, Stripe has test card numbers that can be inserted, e.g. 4242 4242 4242 4242 is successful payment with Visa and 4000 0000 0000 0127 fails with notice about incorrect CVC. The list of distinct errors in payment processing is endless. There might be an insufficient amount of money on the card, or the bank might not allow for a particular transaction type, Internet connection may fail... All these incidents prompt errors. Such a big number of possible edge cases makes testing complicated, but Stripe has solved it in a very convenient way from developer’s perspective and covers all scenarios effectively.

By contrast, PayPal provides you with much less reliable testing options. It offers Sandbox, a second-rate application. We have experienced many bugs with it, instant notifications are usually sent with a delay (sometimes after 5 hours), making testing more difficult and problematic. It is hard to say that it acts the same way as the real instance.

At the end of the day, without testing with a real card we can’t have 100% guarantee that it will work, thus acceptance tests with some small amount should be performed as well.

Our experience with Stripe

In one of the latest Netguru’s projects, I concurrently worked with both leading payment processors in a single project: Stripe and PayPal. It was a great opportunity to compare the services from a developer’s point of view. The client from the event industry wanted to integrate the payment provider with an app that would connect individual clients with event hosts. Initially, the app required one-off payments only, but then we had to implement a subscription model as well.

Both payment gates were almost implemented when the Netguru team stepped in, but they were not working as it had been expected. My job was to refactor the payment processing code and make it work correctly. With Stripe, everything was clear and straightforward. I just had to open the documentation, and everything was in one place. One gem was enough to start off with the integration. PayPal, in contrast, is a much older solution and is not object-oriented. It doesn’t offer a convenient library, so a developer needs to write a solution from scratch. To verify, PayPal IPN webhooks a developer has to write custom verification code, while with Stripe we can rely on the official solution. Apart from that, PayPal is the kind of software that has grown throughout the years, incorporating newer and newer options (and options for options), making it harder to find what you are looking for – even in simple cases. Finally, PayPal’s documentation is not as clear as Stripe’s. With PayPal’s complexity, I had to Google around to find the information I needed more than often.

How to choose the right payment processor?

Choosing a payment gate comes down to your needs and expectations. Each provider excels at different features. PayPal is the most popular one, Braintree is convenient, Klarna has a unique payment model, and all of them have a large market share. Among those, Stripe is the one with the fastest integration process, a feature that is crucial for startups. Before you make a decision, weigh up all the characteristics that are important to your business strategy. Recurring payments are gaining in popularity, so make sure the provider you go for supports them. Let us know if you are building your app in RoR. We’ll be more than happy to help you with integrating the payment processor.

If you need the help of a veteran Ruby on Rails team find out more about working with Netguru.