Behaviour for client-side payment providers.

A payment provider connects the MPP client to a real payment system (Stripe, Tempo, EVM, etc.). Each provider module implements two callbacks that the client transport uses when handling 402 challenges:

1. supports?/3 — check if this provider handles the given method+intent
2. pay/2 — execute payment for a challenge, return a credential

This is the client-side counterpart to MPP.Method (server-side verification). Where a method's verify/2 checks payment proof, PaymentProvider.pay/2 creates payment proof.

Usage

defmodule MyApp.Payments.StripeProvider do
  use MPP.Client.PaymentProvider

  @impl MPP.Client.PaymentProvider
  def supports?(_method, _intent, _config), do: true

  @impl MPP.Client.PaymentProvider
  def pay(challenge, config) do
    # 1. Parse challenge.request for payment details
    # 2. Execute payment (call Stripe API, sign tx, etc.)
    # 3. Return credential with proof payload
    payload = %{"spt" => create_stripe_token(challenge, config)}
    {:ok, %MPP.Credential{challenge: challenge, payload: payload}}
  end
end

Design

Config is explicit. Providers receive a config map on every call — no Application.get_env, no ENV fallback. The caller passes credentials, RPC URLs, and other settings at the call site. This enables multi-tenant usage and parallel testing with different configs.

For multi-provider dispatch, see MPP.Client.MultiProvider.

API Functions