The adapter contract between Accrue and payment processors.

Accrue.Processor is an Elixir behaviour that defines every processor operation Accrue can perform — from creating customers to reporting metered usage. It also acts as a runtime-dispatching facade: callers always write Accrue.Processor.create_customer(...) and the configured adapter (Stripe in production, Fake in tests) handles the actual work.

When you reach for this module

Most of the time you won't call Accrue.Processor directly — the Accrue.Billing context does that for you. You care about this module when:

• Implementing a custom processor adapter — implement this behaviour in your adapter module and point :processor config at it.
• Wiring a test double — Accrue.Processor.Fake already does this; configure it in test.exs or use Accrue.Test.setup_fake_processor/1.
• Reading telemetry events — every facade call emits [:accrue, :processor, <resource>, <action>] spans.

Callback groups

Customer

create_customer/2, retrieve_customer/2, update_customer/3

Subscription

create_subscription/2, retrieve_subscription/2, update_subscription/3, cancel_subscription/2, cancel_subscription/3, resume_subscription/2, pause_subscription_collection/4

SubscriptionItem

subscription_item_create/2, subscription_item_update/3, subscription_item_delete/3

SubscriptionSchedule

subscription_schedule_create/2, subscription_schedule_update/3, subscription_schedule_release/2, subscription_schedule_cancel/2, subscription_schedule_fetch/2

Invoice

create_invoice/2, retrieve_invoice/2, update_invoice/3, finalize_invoice/2, void_invoice/2, pay_invoice/2, send_invoice/2, mark_uncollectible_invoice/2, create_invoice_preview/2

InvoiceItem

invoice_item_create/2, invoice_item_delete/3

Charge and PaymentIntent

create_charge/2, retrieve_charge/2, list_charges/2, create_payment_intent/2, retrieve_payment_intent/2, confirm_payment_intent/3

SetupIntent

create_setup_intent/2, retrieve_setup_intent/2, confirm_setup_intent/3

PaymentMethod

create_payment_method/2, retrieve_payment_method/2, attach_payment_method/3, detach_payment_method/2, list_payment_methods/2, update_payment_method/3, set_default_payment_method/3

Refund

create_refund/2, retrieve_refund/2

Coupon and PromotionCode

coupon_create/2, coupon_retrieve/2, promotion_code_create/2, promotion_code_retrieve/2

Checkout and BillingPortal

checkout_session_create/2, checkout_session_fetch/2, portal_session_create/2

Connect

create_account/2, retrieve_account/2, update_account/3, delete_account/2, reject_account/3, list_accounts/2, create_account_link/2, create_login_link/2, create_transfer/2, retrieve_transfer/2

Usage/Meters

report_meter_event/1

Generic refetch

fetch/2 — routes (object_type_atom, id) to the appropriate retrieve_* callback. Used by the webhook handler to re-fetch objects after receiving an event.

Return types

All adapter callbacks return {:ok, map()} | {:error, Accrue.Error.t()}. Billing context functions promote the 3DS/SCA path to an intent_result tagged tuple ({:ok, :requires_action, payment_intent}) where applicable.

Runtime dispatch

The configured adapter is resolved at call time via Application.get_env(:accrue, :processor, Accrue.Processor.Fake). To use Stripe in production, add to config/runtime.exs:

config :accrue, processor: Accrue.Processor.Stripe

Telemetry

The three facade functions (create_customer/2, retrieve_customer/2, update_customer/3) emit [:accrue, :processor, :customer, <action>] spans. All other operations are instrumented at the Accrue.Billing context level, where the full business operation name is available.