stripe-ruby

Ruby library for the Stripe API.

2,147

661

2,147

View on GitHub View on NPM

Top Related Projects

sinatra

12,448

Classy web-development dressed in a DSL (official / canonical repo)

Active Merchant is a simple payment abstraction library extracted from Shopify. The aim of the project is to feel natural to Ruby users and to abstract as many parts as possible away from the user to offer a consistent interface across all supported gateways.

Quick Overview

Stripe-ruby is the official Ruby library for integrating with Stripe's payment processing API. It provides a convenient way for Ruby developers to interact with Stripe's services, including handling payments, subscriptions, and other financial operations.

Pros

Comprehensive coverage of Stripe's API features
Well-maintained and regularly updated
Excellent documentation and community support
Type-safe API with strong parameter validation

Cons

Learning curve for developers new to Stripe's concepts
Dependency on external service (Stripe) for core functionality
Potential performance overhead for high-volume applications
Requires careful handling of sensitive payment information

Code Examples

Creating a customer:

customer = Stripe::Customer.create({
  email: 'customer@example.com',
  source: 'tok_visa'
})

Creating a charge:

charge = Stripe::Charge.create({
  amount: 2000,
  currency: 'usd',
  customer: customer.id,
  description: 'My First Test Charge (created for API docs at https://www.stripe.com/docs/api)'
})

Creating a subscription:

subscription = Stripe::Subscription.create({
  customer: customer.id,
  items: [
    { price: 'price_H5ggYwtDq4fbrJ' },
  ],
})

Getting Started

Install the gem:

gem install stripe

Set up your Stripe API key:

require 'stripe'
Stripe.api_key = 'sk_test_...'

Make your first API call:

begin
  charge = Stripe::Charge.create({
    amount: 1000,
    currency: 'usd',
    source: 'tok_visa',
    description: 'My First Test Charge'
  })
  puts "Charge successful: #{charge.id}"
rescue Stripe::CardError => e
  puts "Card error: #{e.message}"
rescue Stripe::StripeError => e
  puts "Other Stripe error: #{e.message}"
rescue => e
  puts "Error: #{e.message}"
end

This example creates a simple charge and handles potential errors. Remember to replace 'sk_test_...' with your actual Stripe API key, and never use your live API key in development or testing environments.

Competitor Comparisons

rails

58,710

Ruby on Rails

Pros of Rails

Comprehensive web application framework with a vast ecosystem
Follows convention over configuration, increasing productivity
Extensive built-in testing tools and support

Cons of Rails

Steeper learning curve for beginners
Can be overkill for smaller projects
Performance can be slower compared to lightweight alternatives

Code Comparison

Rails (config/routes.rb):

Rails.application.routes.draw do
  resources :users
  get '/about', to: 'pages#about'
end

Stripe Ruby (example usage):

require 'stripe'
Stripe.api_key = 'sk_test_...'
Stripe::Charge.create({
  amount: 2000,
  currency: 'usd',
  source: 'tok_visa',
  description: 'My First Test Charge (created for API docs)',
})

Rails is a full-featured web application framework, while Stripe Ruby is a specific SDK for integrating Stripe payments. Rails provides a complete structure for building web applications, including routing, database management, and view rendering. Stripe Ruby, on the other hand, focuses solely on Stripe API interactions.

Rails offers more flexibility and features for general web development, but comes with added complexity. Stripe Ruby is simpler and more focused, making it easier to integrate Stripe functionality into existing projects without the overhead of a full framework.

sinatra

12,448

Classy web-development dressed in a DSL (official / canonical repo)

Pros of Sinatra

Lightweight and minimalist web framework, offering more flexibility and control
Easy to learn and use, with a simple DSL for defining routes and handlers
Ideal for small to medium-sized applications and microservices

Cons of Sinatra

Less opinionated and structured compared to full-stack frameworks
Fewer built-in features and conventions, requiring more manual setup
Smaller ecosystem and community compared to larger frameworks

Code Comparison

Sinatra:

require 'sinatra'

get '/' do
  'Hello, World!'
end

Stripe Ruby:

require 'stripe'
Stripe.api_key = 'sk_test_...'

charge = Stripe::Charge.create({
  amount: 2000,
  currency: 'usd',
  source: 'tok_...',
  description: 'My First Test Charge (created for API docs)',
})

While Sinatra is a web framework for building web applications, Stripe Ruby is a library for integrating Stripe payment processing into Ruby applications. Sinatra focuses on routing and handling HTTP requests, while Stripe Ruby provides methods for interacting with Stripe's API. The code examples demonstrate their different purposes: Sinatra defines a simple route, while Stripe Ruby creates a payment charge.

active_merchant

4,597

Pros of Active Merchant

Supports multiple payment gateways, offering flexibility for integrating various payment providers
Provides a unified API for different payment gateways, simplifying integration and maintenance
Has a longer history and larger community, potentially offering more resources and support

Cons of Active Merchant

May have a steeper learning curve due to its broader scope and abstraction layer
Updates and new features might be slower to implement compared to Stripe Ruby
Potentially larger codebase and dependencies, which could impact performance

Code Comparison

Active Merchant:

gateway = ActiveMerchant::Billing::StripeGateway.new(api_key: 'sk_test_...')
response = gateway.purchase(1000, credit_card, {
  description: 'Test purchase'
})

Stripe Ruby:

Stripe.api_key = 'sk_test_...'
charge = Stripe::Charge.create({
  amount: 1000,
  currency: 'usd',
  source: 'tok_visa',
  description: 'Test purchase'
})

The code comparison shows that Active Merchant uses a gateway object and a more abstracted API, while Stripe Ruby offers a more direct and Stripe-specific approach. Active Merchant's code is designed to work with multiple gateways, whereas Stripe Ruby's code is tailored specifically for Stripe's services.

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Stripe Ruby Library

[!TIP] Want to chat live with Stripe engineers? Join us on our Discord server.

The Stripe Ruby library provides convenient access to the Stripe API from applications written in the Ruby language. It includes a pre-defined set of classes for API resources that initialize themselves dynamically from API responses which makes it compatible with a wide range of versions of the Stripe API.

The library also provides other features. For example:

Easy configuration path for fast setup and use.
Helpers for pagination.
Built-in mechanisms for the serialization of parameters according to the expectations of Stripe's API.

Documentation

See the Ruby API docs.

Installation

You don't need this source code unless you want to modify the gem. If you just want to use the package, just run:

gem install stripe

If you want to build the gem from source:

gem build stripe.gemspec

Requirements

Per our Language Version Support Policy, we currently support Ruby 2.7+.

Support for Ruby 2.7 is deprecated and will be removed in upcoming major versions. Read more and see the full schedule in the docs: https://docs.stripe.com/sdks/versioning?lang=ruby#stripe-sdk-language-version-support-policy

Bundler

If you are installing via bundler, you should be sure to use the https rubygems source in your Gemfile, as any gems fetched over http could potentially be compromised in transit and alter the code of gems fetched securely over https:

source 'https://rubygems.org'

gem 'rails'
gem 'stripe'

Usage

The library needs to be configured with your account's secret key which is available in your Stripe Dashboard. Initialize a new client with your API key:

require 'stripe'

client = Stripe::StripeClient.new("sk_test_...")

# list customers
customers = client.v1.customers.list()

# retrieve single customer
customer = client.v1.customers.retrieve('cus_123456789')

Per-request Configuration

For apps that need to use multiple keys during the lifetime of a process, like one that uses Stripe Connect, it's also possible to set a per-request key and/or account:

require "stripe"

client = Stripe::StripeClient.new("sk_test_...")

client.v1.customers.list(
  {},
  {
    api_key: 'sk_test_...',
    stripe_account: 'acct_...',
    stripe_version: '2018-02-28',
  }
)

StripeClient vs legacy pattern

We introduced the StripeClient class in v13 of the Ruby SDK. The legacy pattern used prior to that version is still available to use but will be marked as deprecated soon. Review the migration guide to use StripeClient to move from the legacy pattern.

Once the legacy pattern is deprecated, new API endpoints will only be accessible in the StripeClient. While there are no current plans to remove the legacy pattern for existing API endpoints, this may change in the future.

Accessing resource properties

Both indexer and accessors can be used to retrieve values of resource properties.

customer = client.v1.customers.retrieve('cus_123456789')
puts customer['id']
puts customer.id

NOTE: If the resource property is not defined, the accessors will raise an exception, while the indexer will return nil.

customer = client.v1.customers.retrieve('cus_123456789')
puts customer['unknown'] # nil
puts customer.unknown # raises NoMethodError

Accessing a response object

Get access to response objects by using the last_response property of the returned resource:

customer = client.v1.customers.retrieve('cus_123456789')

print(customer.last_response.http_status) # to retrieve status code
print(customer.last_response.http_headers) # to retrieve headers

If you are accessing a response field with custom hashes provided by you, such as Customer.metadata, please access your fields with the [] accessor.

Configuring a proxy

A proxy can be configured with Stripe.proxy:

Stripe.proxy = 'https://user:pass@example.com:1234'

Configuring an API Version

By default, the library will use the API version pinned to the account making a request. This can be overridden with this global option:

Stripe.api_version = '2018-02-28'

See versioning in the API reference for more information.

Configuring CA Bundles

By default, the library will use its own internal bundle of known CA certificates, but it's possible to configure your own:

Stripe.ca_bundle_path = 'path/to/ca/bundle'

Configuring Automatic Retries

You can enable automatic retries on requests that fail due to a transient problem by configuring the maximum number of retries:

Stripe.max_network_retries = 2

Various errors can trigger a retry, like a connection error or a timeout, and also certain API responses like HTTP status 409 Conflict.

Idempotency keys are added to requests to guarantee that retries are safe.

Configuring Timeouts

Open, read and write timeouts are configurable:

Stripe.open_timeout = 30 # in seconds
Stripe.read_timeout = 80
Stripe.write_timeout = 30 # only supported on Ruby 2.6+

Please take care to set conservative read timeouts. Some API requests can take some time, and a short timeout increases the likelihood of a problem within our servers.

Logging

The library can be configured to emit logging that will give you better insight into what it's doing. The info logging level is usually most appropriate for production use, but debug is also available for more verbosity.

There are a few options for enabling it:

Set the environment variable STRIPE_LOG to the value debug or info:
```
$ export STRIPE_LOG=info
```
Set Stripe.log_level:
```
Stripe.log_level = Stripe::LEVEL_INFO
```

Instrumentation

The library has various hooks that user code can tie into by passing a block to Stripe::Instrumentation.subscribe to be notified about specific events.

`request_begin`

Invoked when an HTTP request starts. Receives RequestBeginEvent with the following properties:

method: HTTP method. (Symbol)
path: Request path. (String)
user_data: A hash on which users can set arbitrary data, and which will be passed through to request_end invocations. This could be used, for example, to assign unique IDs to each request, and it'd work even if many requests are running in parallel. All subscribers share the same object for any particular request, so they must be careful to use unique keys that will not conflict with other subscribers. (Hash)

`request_end`

Invoked when an HTTP request finishes, regardless of whether it terminated with a success or error. Receives RequestEndEvent with the following properties:

duration: Request duration in seconds. (Float)
http_status: HTTP response code (Integer) if available, or nil in case of a lower level network error.
method: HTTP method. (Symbol)
num_retries: The number of retries. (Integer)
path: Request path. (String)
user_data: A hash on which users may have set arbitrary data in request_begin. See above for more information. (Hash)
request_id: HTTP request identifier. (String)
response_header: The response headers. (Hash)
response_body = The response body. (String)
request_header = The request headers. (Hash)
request_body = The request body. (String)

Example

For example:

Stripe::Instrumentation.subscribe(:request_end) do |request_event|
  # Filter out high-cardinality ids from `path`
  path_parts = request_event.path.split("/").drop(2)
  resource = path_parts.map { |part| part.match?(/\A[a-z_]+\z/) ? part : ":id" }.join("/")

  tags = {
    method: request_event.method,
    resource: resource,
    code: request_event.http_status,
    retries: request_event.num_retries
  }
  StatsD.distribution('stripe_request', request_event.duration, tags: tags)
end

How to use undocumented parameters and properties

In some cases, you might encounter parameters on an API request or fields on an API response that arenât available in the SDKs. This might happen when theyâre undocumented or when theyâre in preview and you arenât using a preview SDK. See undocumented params and properties to send those parameters or access those fields.

Writing a Plugin

If you're writing a plugin that uses the library, we'd appreciate it if you identified using #set_app_info:

Stripe.set_app_info('MyAwesomePlugin', version: '1.2.34', url: 'https://myawesomeplugin.info')

This information is passed along when the library makes calls to the Stripe API.

Telemetry

By default, the library sends telemetry to Stripe regarding request latency and feature usage. These numbers help Stripe improve the overall latency of its API for all users, and improve popular features.

You can disable this behavior if you prefer:

Stripe.enable_telemetry = false

Types

In v14.0.0 and newer, the library provides RBI static type annotations. See the wiki for an detailed guide.

Please note that these types are available only for static analysis and we only support RBIs at the moment. Please report an issue if you find discrepancies or have issues using types.

The RBIs can be found in the rbi/stripe/ directory, and to decrease Tapioca loading time we pack the gem with the combined RBI at rbi/stripe.rbi.

Types and the Versioning Policy

We release type changes in minor releases. While stripe-ruby follows semantic versioning, our semantic versions describe the runtime behavior of the library alone. Our type annotations are not reflected in the semantic version. That is, upgrading to a new minor version of stripe-ruby might result in your type checker producing a type error that it didn't before. You can use ~> x.x or x.x.x constrain the version of stripe-ruby in your Gemfile to a certain version or range of stripe-ruby.

Types and API Versions

The types describe the Stripe API version that was the latest at the time of release. This is the version that your library sends by default. If you are overriding Stripe.api_version / stripe_version on the StripeClient, or using a webhook endpoint tied to an older version, be aware that the data you see at runtime may not match the types.

Public Preview SDKs

Stripe has features in the public preview phase that can be accessed via versions of this package that have the -beta.X suffix like 11.2.0-beta.2. We would love for you to try these as we incrementally release new features and improve them based on your feedback.

To install, pick the latest version with the beta suffix by reviewing the releases page and use it in the gem install command:

gem install stripe -v <replace-with-the-version-of-your-choice>

Note There can be breaking changes between two versions of the public preview SDKs without a bump in the major version. Therefore we recommend pinning the package version to a specific version in your Gemfile. This way you can install the same version each time without breaking changes unless you are intentionally looking for the latest version of the public preview SDK.

We highly recommend keeping an eye on when the beta feature you are interested in goes from beta to stable so that you can move from using a beta version of the SDK to the stable version.

Some preview features require a name and version to be set in the Stripe-Version header like feature_beta=v3. If your preview feature has this requirement, use the Stripe.add_beta_version function (available only in the public preview SDKs):

Stripe.add_beta_version("feature_beta", "v3")

Private Preview SDKs

Stripe has features in the private preview phase that can be accessed via versions of this package that have the -alpha.X suffix like 11.2.0-alpha.2. You can install the private preview SDKs by following the same instructions as for the public preview SDKs above and replacing the term beta with alpha. Note that access to specific private preview API features may require separate approval.

Custom requests

This feature is only available from version 13 of this SDK.

If you:

would like to send a request to an undocumented API (for example you are in a private beta)
prefer to bypass the method definitions in the library and specify your request details directly,
used the method Stripe::APIResource.request(...) to specify your own requests, which was removed in v13+

you can now use the raw_request method on StripeClient.

client = Stripe::StripeClient.new('sk_test_...')
resp = client.raw_request(:post, "/v1/beta_endpoint", params: {param: 123}, opts: {stripe_version: "2022-11-15; feature_beta=v3"})

# (Optional) resp is a StripeResponse. You can use `Stripe.deserialize` to get a StripeObject.
deserialized_resp = client.deserialize(resp.http_body)

Support

New features and bug fixes are released on the latest major version of the Stripe Ruby library. If you are on an older major version, we recommend that you upgrade to the latest in order to use the new features and bug fixes including those for security vulnerabilities. Older major versions of the package will continue to be available for use, but will not be receiving any updates.

Development

[!WARNING] External contributions to this repo from first-time contributors are currently on hiatus. If you'd like to see a change made to the package, please open an issue.

Contribution guidelines for this project

The test suite depends on stripe-mock, so make sure to fetch and run it from a background terminal (stripe-mock's README also contains instructions for installing via Homebrew and other methods):

go install github.com/stripe/stripe-mock@latest
stripe-mock

We use just for common development tasks. You can install it or run the underlying commands directly (by copying them from the justfile). Common tasks include:

Run all tests:

just test
# or: bundle exec rake test

Run a single test suite:

bundle exec ruby -Ilib/ test/stripe/util_test.rb

Run a single test:

bundle exec ruby -Ilib/ test/stripe/util_test.rb -n /should.convert.names.to.symbols/

Run the linter:

just lint
# or: bundle exec rubocop

Update bundled CA certificates from the Mozilla cURL release:

just update-certs
# or: bundle exec rake update_certs

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

Top Related Projects

Quick Overview

Pros

Cons

Code Examples

Getting Started

Competitor Comparisons

Pros of Rails

Cons of Rails

Code Comparison

Pros of Sinatra

Cons of Sinatra

Code Comparison

Pros of Active Merchant

Cons of Active Merchant

Code Comparison

Convert designs to code with AI

README

Stripe Ruby Library

Documentation

Installation

Requirements

Bundler

Usage

Per-request Configuration

StripeClient vs legacy pattern

Accessing resource properties

Accessing a response object

Configuring a proxy

Configuring an API Version

Configuring CA Bundles

Configuring Automatic Retries

Configuring Timeouts

Logging

Instrumentation

request_begin

request_end

Example

How to use undocumented parameters and properties

Writing a Plugin

Telemetry

Types

Types and the Versioning Policy

Types and API Versions

Public Preview SDKs

Private Preview SDKs

Custom requests

Support

Development

Top Related Projects

Convert designs to code with AI

NPM DownloadsLast 30 Days

`request_begin`

`request_end`