What reaches your payment provider
Not everything you send on a charge is forwarded to the provider that processes it, and what is forwarded is a property of your connection, not of the API — a field you rely on as chargeback evidence may never arrive, and a field you assumed was private may be passed on in full.
The table below is true of the connection most merchants are on, not all of them. On some connections the billing block is not assembled at all — billing_address and buyer_email are accepted, stored, and go no further — while the whole metadata map goes to the processor instead. No field on the API tells you which you are on; ask us, and design your dispute process around the answer.
Can reach your provider
| Field | Why it matters there |
|---|---|
billing_address | Where the billing block is assembled, this is what runs Address Verification and is the strongest evidence when defending an "I did not authorise this" chargeback. ⚠️ AVS activates per gateway and is opt-in — on a connection that does not assemble the block, sending it does nothing at all. |
buyer_email | Forms part of that same billing block, so it travels only where the block does. |
rule_tags | Matched by your provider's own rules. Up to 5 short labels, no personal data — values shaped like an email or key are rejected. Honoured only where your provider supports orchestration rules; elsewhere the charge is refused pre-flight with capability_not_supported. |
| One order reference | Read from metadata, first match wins across order_id, reference and merchant_reference. |
Never forwarded
order/lineItems- the buyer's phone and shipping address
Depends on your connection — do not assume either way
- the rest of
metadata— see below.
metadata is your record — do not rely on it reaching, or not reaching, the processor
metadata is the system-of-record: echoed on the create response and read back from GET /v1/payment_intents/{id} (Metadata has the per-endpoint caps and what is stripped). How much of it travels depends on the endpoint and the connection: the hosted-checkout path forwards the whole map; on the discrete charge path most connections forward only the single order reference, and at least one forwards every non-reserved key. So it is neither dependable evidence nor reliably private — evidence for a dispute has to travel as billing_address, buyer_email or a rule_tags label, and nothing goes in metadata that you would not send to a third party.
Send billing_address on every card charge: on a connection that uses it, a merchant who never sends it has never had Address Verification run on a single charge, with no warning either way, and it costs nothing on the connections that ignore it. Send the buyer's name as buyer.first_name and buyer.last_name — structured, and they take priority over every other source when the billing block is built; a single free-text name is never split and does not reach the billing block. They belong to the charge, not the buyer profile, so send them on every charge (Putting a name on the payment). Forwarding of buyer_email and the billing block is an account-level setting, so a successful response does not by itself confirm the block was sent — ask us if you need it enabled.