Pay for Rails: five payment processors behind one engine

Five processors behind one set of Rails models

Pay is a payments engine for Ruby on Rails 6.0 and higher, and the way it is organised is by object rather than by gateway. Its documentation is split into Customers, Payment Methods, Charges, Subscriptions, Routes and Webhooks, and Customizing Pay Models, so application code targets those engine concepts while the provider sits behind them. The processor list names five entries: Stripe, Paddle, Braintree, Lemon Squeezy and a Fake Processor.

The engine is candid about the price of that abstraction. Its own caveat reads, "We make our best attempt to standardize the different payment providers," and the lines that follow say what to do about the gap: providers function differently, so anything beyond the shared path should stay on a single provider to avoid discrepancies. That sentence is the design contract. A team intending to hold more than one gateway at once is buying a common customer, charge and subscription model, not identical behaviour across five back ends.

SCA and PayPal coverage differ by provider

Capability claims are not uniform across the five processors. Stripe is the only entry tied to an SCA reference, and Paddle is the only one described as SCA compatible and PayPal capable. Braintree and Lemon Squeezy are listed for PayPal, with no SCA claim attached to either. The Fake Processor sits in the same list as a real gateway but is documented as the option for generic trials without cards, free subscriptions and testing, which answers the first question a new project asks: how do subscriptions look before a merchant account exists.

Counting the documented integrations gives a wider picture than the bullet list. Two more names appear lower in the documentation, Asaas and Square, both marked Community, both pointing outside this repository. The headline claim of five supported processors sits next to seven documented entry points, and the four real gateways do not carry the same feature set as one another. Any comparison between them has to happen at the provider page level rather than by asking whether the engine supports PayPal at all.

Stripe is documented against API version 2022-11-15

The Stripe entry is the only processor bullet that names an API version, and the string it names is `2022-11-15`. Set against the engine's own numbering, that pin is the detail worth pausing on. The repository tags three versions inside six days: v11.8.0 on 2026-09-20, then v12.0.0 and v12.1.0 both on 2026-09-21, and the last push was on 2026-09-26. A Stripe API version from 2022 sitting underneath a v12 gem shipped in September 2026 raises a question the README leaves open, and the README shows no configuration key that would move the integration forward without editing the gem itself. For a team that needs Stripe features added after that date, this is the first file to read.

The README carries no install command

The README carries no install command at all. What it offers is a pointer: `docs/1_installation.md` for installation and `docs/2_configuration.md` for configuration. A new user therefore has no line to copy, no gem version constraint to pin and no generator invocation to run, and those three things live in the first two files of the docs tree. After those, the tree maps the build order: `docs/3_customers.md`, `docs/4_payment_methods.md`, `docs/5_charges.md`, `docs/6_subscriptions.md`, `docs/7_webhooks.md`, then `docs/8_customizing_models.md`.

Two shortcuts exist for people who would rather not start from an empty application. The README points to Jumpstart, a Rails starter kit that ships with Pay already integrated, and to a video getting started guide linked from the tutorial section. Neither replaces the configuration document, because the provider you settle on decides which keys you set there, and that provider list is longer than the five bullets at the top once the community gems are counted.

Asaas and Square ship as separate gems

Two of the documented providers are not in this repository. Asaas is documented by a link to the pay-asaas gem under another maintainer's account, and Square to pay-square, likewise maintained elsewhere. The consequence is that a sixth processor is never a matter of dropping a file into this codebase, and the project wrote down the route anyway at `docs/contributing/adding_a_payment_processor.md`.

For an adopter this splits the upgrade burden in half. Engine upgrades follow the top-level `UPGRADE.md`, while a community gem follows its own repository and its own schedule, and nothing in either place coordinates the two. A Rails shop running subscriptions through Asaas while testing against the Fake Processor is already maintaining a dependency chain the engine does not describe, so budget time for it rather than treating provider choice as a single config change.

Marketplace coverage stops at Stripe Connect

Only one of the four real gateways has a marketplace document. `docs/marketplaces/stripe_connect.md` covers Stripe Connect, and there is no counterpart for Paddle, Braintree, Lemon Squeezy or the Fake Processor. A marketplace build on Pay is therefore a Stripe Connect build with the standard customer and subscription layer wrapped around it, which is a workable shape for a single-gateway team and a dead end for anyone whose payout model requires the other three.

That gap is a documentation gap rather than a stated limitation, and the difference matters during evaluation. A missing page can mean a feature is unsupported or simply undocumented, and the repository does not say which. If payouts to connected accounts sit on the roadmap, read that one file first, then look at what the Stripe Connect page leaves to application code.

The pull request gate runs standardrb, not RuboCop

The root layout carries two style configuration files, `.rubocop.yml` and `.standard.yml`, while the contributing section names exactly one lint command, `bundle exec standardrb`, next to database preparation and the test suite. A fork that copies the root will enforce Standard's rules on every pull request and carry a RuboCop configuration the documented gate never reads. Which one wins in your own CI depends on what you wire up rather than on what sits in the repository.

The three lines to run before opening a pull request are:

bin/rails db:test:prepare
bin/rails test
bundle exec standardrb

Prepare the test database, run the suite, then check style. The same section documents how to vary the database itself: uncomment the `DATABASE_URL` entry matching the database you want in `.devcontainer/devcontainer.json` and rebuild the devcontainer, so local runs are not pinned to one engine.

Appraisals and gemfiles drive dependency coverage

The root layout also explains how this gem gets tested against dependency versions. `Appraisals` sits beside a `gemfiles/` directory, `Gemfile` and `Gemfile.lock`, with `pay.gemspec`, `Rakefile`, `test/` and the db directory completing the set. Appraisals plus a directory of gemfiles is the usual arrangement for running one gem against several dependency sets, which is the right shape for a library whose whole purpose is to sit inside somebody else's dependency tree and keep working across their upgrades.

Upgrades come with a written path rather than a single line: the README sends anyone moving from an earlier version to `UPGRADE.md` for required changes and migration steps, which is where a jump across major versions gets explained. On terms, the gem ships under the MIT License with `MIT-LICENSE` at the repository root, and the README adds no warranty or liability text of its own, so anyone who needs those settled reads the file rather than the page.

Editorial conclusion

Adopt Pay when one team has to run subscriptions across Stripe, Paddle, Braintree or Lemon Squeezy and shared customer, charge and subscription objects matter more than provider specific behaviour. Skip it when marketplace payouts run on anything but Stripe Connect, the only gateway with a marketplace page, or when Asaas or Square is the gateway you need, since both live in separate gems. Open docs/1_installation.md first, then check whether API version 2022-11-15 covers the Stripe features you plan to use.

Frequently asked questions

Official sources

1. License: MIT
2. pay-rails/pay on GitHub
3. Project website
4. README
5. Releases