TigerStripe
Comprehensive Elixir SDK for the Stripe API, with verified 1:1 feature parity to the official Ruby SDK.
Note: This is not an official Stripe SDK. Stripe does not publish a first-party Elixir library. This project is generated from the same OpenAPI spec that Stripe uses to build their official SDKs, follows the same service architecture, and is tested for 1:1 parity against the official Ruby SDK. The goal is an idiomatic Elixir experience with the same API coverage.
What's Included
The SDK layer provides typed resource structs, typed request params, per-event modules, and auto-paging pagination — all generated from the spec with full documentation. The client layer handles HTTP execution via Finch with connection pooling, automatic retries, request encoding, response deserialization, and telemetry.
Together, the full V1 + V2 API surface is covered: 190 service modules, 307 typed resource structs, 523 typed params modules, webhook signature verification, OAuth, file uploads, streaming responses, and per-event typed modules.
Coming from the Ruby SDK
TigerStripe has the same API coverage as the official Ruby SDK but follows Elixir conventions. Three things work differently:
Service modules instead of resource methods. Ruby calls methods on
resource classes (Stripe::Charge.create). Elixir uses dedicated service
modules — the same internal architecture the Ruby SDK uses, surfaced
explicitly:
# Ruby
charge = Stripe::Charge.create({amount: 2000, currency: "usd"})# Elixir
{:ok, charge} = Stripe.Services.ChargeService.create(client, %{amount: 2000, currency: "usd"})Explicit client argument. Ruby uses a global Stripe.api_key. Elixir
passes a client struct to every call — no global mutable state, safe for
concurrent use with multiple API keys or connected accounts:
# Ruby
Stripe.api_key = "sk_test_..."
charge = Stripe::Charge.retrieve("ch_123")# Elixir
client = Stripe.client()
{:ok, charge} = Stripe.Services.ChargeService.retrieve(client, "ch_123")Tuples instead of exceptions. Ruby raises Stripe::StripeError on
failure. Elixir returns {:ok, result} / {:error, %Stripe.Error{}} tuples
for pattern matching:
# Ruby
begin
charge = Stripe::Charge.create(params)
rescue Stripe::CardError => e
puts e.message
end# Elixir
case Stripe.Services.ChargeService.create(client, params) do
{:ok, charge} -> charge
{:error, %Stripe.Error{type: :card_error} = err} -> Logger.warning(err.message)
endEverything else — endpoint paths, parameter names, resource fields, webhook payloads, pagination, file uploads, OAuth — is 1:1 with the Ruby SDK.
Installation
With Igniter (recommended for Phoenix)
Beta: The Igniter installer is new and under active testing. Report issues here.
If your project uses Igniter, one command sets up everything — config, webhook plug, controller, and route:
mix igniter.install tiger_stripeSee the Igniter Installer guide for a detailed walkthrough of what the installer does.
Manual
Add tiger_stripe to your dependencies in mix.exs:
def deps do
[
{:tiger_stripe, "~> 0.1.10"}
]
endRequires Elixir 1.19+ and OTP 27+.
Configuration
# config/dev.exs — sandbox credentials
config :tiger_stripe,
api_key: "sk_test_...",
webhook_secret: "whsec_test_..."
# config/runtime.exs — production credentials
if config_env() == :prod do
config :tiger_stripe,
api_key: System.fetch_env!("STRIPE_SECRET_KEY"),
webhook_secret: System.fetch_env!("STRIPE_WEBHOOK_SECRET")
endOptional global defaults (all have sensible defaults if omitted):
config :tiger_stripe,
api_key: "sk_test_...",
webhook_secret: "whsec_...",
api_version: "2026-01-28.clover", # pin API version
client_id: "ca_...", # OAuth client ID (Connect platforms)
max_retries: 3, # default: 2
open_timeout: 30_000, # connection timeout in ms
read_timeout: 80_000 # read timeout in msSee the Getting Started guide for all config options and precedence rules.
Quick Start
client = Stripe.client()
# Create a customer
{:ok, customer} = Stripe.Services.CustomerService.create(client, %{
email: "jane@example.com"
})
# Retrieve a payment intent
{:ok, intent} = Stripe.Services.PaymentIntentService.retrieve(client, "pi_123")
# List charges (returns a typed ListObject)
{:ok, charges} = Stripe.Services.ChargeService.list(client, %{"limit" => 10})Responses are automatically deserialized into typed structs:
customer.id #=> "cus_abc123"
customer.email #=> "jane@example.com"
customer.__struct__ #=> Stripe.Resources.CustomerOverride config per-client for Connect or multi-key scenarios:
client = Stripe.client(stripe_account: "acct_connected")
client = Stripe.client("sk_test_other_key", max_retries: 5)Features
SDK
- Full API coverage — every V1 and V2 endpoint from the OpenAPI spec, with dedicated service modules matching the Ruby SDK layout
- Typed resources — API responses are deserialized into typed Elixir structs
with
@type tdefinitions, expandable field support, and inner types - Typed params — request parameters have dedicated struct modules with
@typedocannotations sourced from the OpenAPI spec - Per-event typed modules — V2 and thin V1 events get dedicated modules
with typed data structs and
fetch_related_object/2 - Auto-paging pagination — lazy
Stream-based iteration for V1 lists, search results, and V2 lists - Webhook verification — HMAC-SHA256 signature verification with constant-time comparison and timestamp tolerance
- OAuth —
authorize_url,token, anddeauthorizefor Stripe Connect - Documentation —
@moduledoc,@doc,@typedoc,@spec, and@deprecatedon all generated modules, sourced from the OpenAPI spec
Client
- Finch HTTP client — modern HTTP/2-capable client with connection pooling via NimblePool (replaces legacy Hackney)
- Automatic retries — exponential backoff with jitter, respects
stripe-should-retryheader, auto-generated idempotency keys for V2 - Request encoding — V1 form-encoded, V2 JSON, automatic multipart for file uploads
- Response deserialization — JSON to typed structs via object type registry
- Streaming — chunked response streaming for large payloads and SSE
- Telemetry —
:telemetryevents for request lifecycle observability - Per-client configuration — explicit struct with no global state, safe for concurrent use with multiple API keys or connected accounts
- Test stubs — process-scoped HTTP stubs via NimbleOwnership for
async: truetests
Guides
- Getting Started — installation, configuration, first API call, pagination, error handling
- Igniter Installer — one-command Phoenix setup (beta)
- Webhooks — signature verification, WebhookPlug setup, typed event modules
- Connect & OAuth — connected accounts, OAuth flow, multi-tenant patterns
- Testing — process-scoped HTTP stubs with
async: truesupport - Telemetry — request lifecycle events, logging, metrics
Development
# Sync the OpenAPI spec
bash scripts/sync_openapi.sh
# Generate the SDK
mix stripe.generate --clean --stats
# Verify
mix compile --warnings-as-errors
mix test
mix docs --warnings-as-errors
bash scripts/diff_ruby.shCode Generation
The SDK is auto-generated from Stripe's unified OpenAPI spec (spec3.sdk.json)
via mix stripe.generate. The generator produces 1,044 files:
- 190 service modules (189 generated + 1 hand-written
OAuthService) - 307 resource structs with
@type t, expandable fields, and inner types - 523 params modules with
@typedocfield annotations - 2 registries (object types and event types)
- 22 event modules (20 per-event typed + 1 constants + 1 unknown fallback)
A small set of overrides handle cases where the spec's metadata doesn't match the Ruby SDK's service layout. Each override is documented with a reason and a reference to the corresponding Ruby service file, enforced by tests.
Parity Testing
Ruby SDK parity is a hard invariant. CI runs scripts/diff_ruby.sh to verify
1:1 service file and endpoint coverage. The test suite includes dedicated
parity assertions comparing the generated endpoint set against both the OpenAPI
spec and the Ruby SDK fixture tree.
License
MIT License. See LICENSE for details.