Add retry_attempt and checkout_session_id to the payments list response

Problem

GET /payments omits several fields that are present on GET /payments/{id}, which forces a fetch per payment for work that should be one list call.

Missing from the list item today:

• retry_attempt
• checkout_session_id
• error_code and error_message
• billing (so no billing country)
• card_issuing_country and card_type

The list does carry status, currency, payment_method, payment_method_type, card_network, card_last_four, invoice_id, subscription_id, metadata, refund_status, dispute_status and payment_provider.

Why it matters

Measuring an authorization rate is impractical. A merchant wanting a decline-rate breakdown by country has to page the list, then issue an individual fetch for every row to get error_code and billing country. With page_size capped at 100, that is one request per payment across their whole history. card_issuing_country, which is the better signal for a card-issuance rate than billing country, is also single-fetch only.

Retries cannot be excluded from a list-derived rate. Our own renewal retries appear as separate payment rows. Without retry_attempt on the list there is no way to filter to first attempts, so any rate computed from the list silently over-counts attempts.

Response-loss recovery is weaker than it needs to be. When a merchant loses a checkout session_id, the documented fallback is to scan GET /payments by created_at and match on their own reference in metadata. That works, but because checkout_session_id is not on the list item they cannot confirm the match against the session, only against their own metadata.

Requested

Add to the payments list item:

1. retry_attempt — unblocks first-attempt filtering
2. error_code and error_message — unblocks decline analysis without N fetches
3. checkout_session_id — completes the recovery path
4. billing or at minimum a billing country field, and card_issuing_country

Items 1 and 2 are the highest value, since together they turn authorization-rate measurement from N+1 requests into one.

Related

Two adjacent inconsistencies worth cleaning up in the same pass:

• updated_at exists on PaymentResponse but is always null. It should either be populated or removed.
• retry_attempt counts our scheduled retries, but manual retries number from their own sequence and payment-method-update charges keep 0. Worth documenting the semantics wherever it is exposed, since merchants reasonably read it as an attempt counter.