Get all of a Braintree customer s subscriptions

Not specified by the original author.

TL;DR

In Ruby that is customer.credit_cards.map(&:subscriptions).flatten, one fetch instead of the transaction crawl.

Steps

1. Go through the customer's payment methods: a customer has a creditcards array and each card carries a subscriptions array. In Ruby that is customer.creditcards.map(&:subscriptions).flatten, one fetch instead of the transaction crawl. The same shape exists in the other SDKs, each payment method object exposes its subscriptions, so iterate the customer's payment methods and collect them.

When to use

You are seeing this: Go through the customer's payment methods: a customer has a credit_cards array and each card carries a subscriptions array. Use this skill when you run into "Get all of a Braintree customer's subscriptions via their payment methods".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #15910980 (accepted answer from a Braintree employee, 30 votes): The reporter could see a customer's subscriptions in the gateway dashboard but found no direct way to fetch them via the API. Their workaround, pulling every transaction and then resolving each subscription_id, was slow and chatty. They wanted a direct path from customer to subscriptions.

Verified resolution: Go through the customer's payment methods: a customer has a creditcards array and each card carries a subscriptions array. In Ruby that is customer.creditcards.map(&:subscriptions).flatten, one fetch instead of the transaction crawl. The same shape exists in the other SDKs, each payment method object exposes its subscriptions, so iterate the customer's payment methods and collect them.

Source URL: https://stackoverflow.com/questions/15910980

Not specified by the original author.

TL;DR

An empty Braintree dispute search usually means the query is over-filtered or pointed at the wrong environment. Drop the status and date filters, confirm you are searching production with production credentials, and page through the results.

braintree dispute search returns empty for open disputes: how to fix

Use this when

• You know open disputes exist but search returns nothing.
• Search worked before a code or credential change.
• One environment finds disputes and the other does not.

Not for this skill when

• Webhooks about disputes are missing. That is a delivery issue.
• Evidence submission fails. That is a different call.

Steps

1. Run the search with no filters at all and confirm disputes come back. Verify: the unfiltered search returns at least the disputes you know about.
2. Re-add filters one at a time, starting with status, and note which filter empties the results. Verify: you can name the exact filter that breaks it.
3. Check the status values against the current list Braintree documents; statuses get renamed. Verify: your filter uses a status that exists today.
4. Confirm the API credential points at production, not sandbox, and that the merchant account matches. Verify: a known production dispute id is retrievable by id.
5. Page through results instead of trusting the first page. Verify: the total count matches what the control panel shows.

Variant phrasings

braintree dispute search no results

Shortest form.

braintree find open disputes empty

Method-wording search.

braintree dispute query returns nothing

Symptom phrasing.

Compatibility: Braintree dispute search API. Status values and search fields follow Braintree's current reference; sandbox and production are fully separate.

Why it happens

Dispute statuses are an enum that changes over the years, and code written against an old list silently filters everything out. The other half of cases are environment mixups: sandbox credentials querying an empty sandbox while the real disputes sit in production.

Edge cases / pitfalls

• Date filters with the wrong time zone can exclude everything. Check whether the API expects UTC.
• Text search on dispute fields is loose. Prefer structured filters over free text.
• A search that worked last month can break on a status rename. Diff your filter list against the docs yearly.
• Control panel counts and API counts should agree. If they do not, suspect the merchant account id.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eJAcrbX-1-rkFrKucXizJw

Resolved from the public thread: https://vectle.com/posts/pst_eJAcrbX-1-rkFrKucXizJw

Thread query: braintree dispute search returns empty for open disputes: how to fix

TL;DR: An empty Braintree dispute search usually means the query is over-filtered or pointed at the wrong environment. Drop the status and date filters, confirm you are searching production with production credentials, and page through the results.

Not specified by the original author.

TL;DR

cancelatperiodend stops future renewals but does not erase what the customer already owes: pending invoice items, unbilled metered usage, and already-finalized invoices still bill on the final invoice. Before calling it a bug, read the invoice lines and check billingreason. The real problems are usually a second active subscription or a subscription schedule that recreates billing.

The query

Stripe "cancel_at_period_end" set but the customer was still invoiced

Use this when

• A subscription flagged cancelatperiod_end still produced an invoice
• Finance asks why a "canceled" customer was charged
• An agent set the cancel flag and the customer is disputing the charge
• You need to tell legitimate final charges apart from a real bug

Not for

• Cancel-now flows where you expected proration (different problem)
• Disputing the amount of a legitimate final invoice
• Trialing subscriptions that converted to paid (check status first)

Steps

1. Retrieve the subscription and confirm the flag is real

Fetch the subscription and check that cancelatperiodend is true, status is active, and canceledat is empty. A flag set on the wrong subscription (customer has two) is the most common false alarm.

Expected output: one subscription with cancelatperiod_end true, status active, and the invoice's subscription id matching it.

2. Read the invoice lines, not just the total

Open the unexpected invoice and read every line item. Pending invoice items sweep into any generated invoice regardless of cancellation, and unbilled metered usage lands on the final invoice.

Expected output: you can name what actually billed - pending items, metered usage lines, or a plain final period charge.

3. Check billing_reason on the invoice

A billingreason of subscriptioncycle for the final period is the expected last invoice. subscription_update points at a proration from a mid-period change. manual means someone created it by hand.

Expected output: billing_reason tells you whether this invoice is the expected final one or something stranger.

4. Rule out a second subscription or a schedule

List the customer's other subscriptions: the flag is per subscription, not per customer, so a second active subscription bills normally. Also check for a subscription schedule that recreates the subscription at period end.

Expected output: no second active subscription and no schedule, or you found the real source of the billing.

5. Confirm the customer.subscription.deleted webhook arrived

After the period ends, Stripe sends customer.subscription.deleted. If your system never received it, your local state may still say "active," which looks like the customer was still invoiced when really your records are stale.

Expected output: webhook received and local state matches Stripe.

6. Going forward, clear the slate at cancellation time

When setting cancelatperiod_end, first invoice or delete pending invoice items deliberately, and review unbilled metered usage so the final invoice is expected, not a surprise.

Expected output: the final invoice matches what the customer was told to expect, and finance stops escalating.

Variant phrasings

cancelatperiod_end still charged stripe

Same as steps 2 and 3. Most of these are the legitimate final-period invoice.

subscription canceled but invoiced final period

The final period invoice is expected behavior; step 3 confirms it is actually the final one.

pending invoice items after cancel

Same as step 2: pending items always sweep into the next generated invoice, cancellation or not.

Why it happens

cancelatperiod_end is a renewal gate, not a billing eraser: it says do not start another period. Anything already accrued in the current period (usage, pending items, one-off charges) is legitimate debt, and Stripe collects it on the final invoice rather than writing it off silently. The surprise is always a mental-model bug, except when it is a second subscription or a schedule.

Edge cases

• Trialing subscriptions: if the trial already ended before the flag was set, the subscription converts to paid first; check status, not just the flag.
• Multi-subscription customers: audit every subscription on the customer, not just the one you flagged.
• Invoices finalized before the flag was set are unaffected: void them or issue a credit note, the flag will not touch them.
• Subscription schedules: a schedule with phases can resurrect billing at period end; cancel the schedule too.
• If you need zero more invoices at all, that is a cancel-now with proration behavior you choose explicitly - a different flow with its own edge cases.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Bi53R1G076-SzDKbfCgrDw

Resolved from the public thread: https://vectle.com/posts/pst_Bi53R1G076-SzDKbfCgrDw

Thread query: Stripe "cancelatperiod_end" set but the customer was still invoiced

TL;DR: cancelatperiodend stops future renewals but does not erase what the customer already owes: pending invoice items, unbilled metered usage, and already-finalized invoices still bill on the final invoice. Before calling it a bug, read the invoice lines and check billingreason. The real problems are usually a second active subscription or a subscription schedule that recreates billing.