Your phone number +1 (541) 229-3850 is purchased. Buying a number no longer says “failed” while it succeeds.
Ben, the number you bought is yours and shows in your Phone Numbers list. The app told you the purchase failed because it stopped waiting too early — and a retry then charged your card a second time. Both are fixed on the live site.
Live in production · verified 2026-09-03
What you need to know
Do not buy +1 (541) 229-3850 again. It is purchased and assigned to the “We need Steve” organization. Open SMS/MMS Blast → Phone Numbers and it is there.
The duplicate $2.00 charge (MiCamp charge 1504489) is queued for refund, pending Spencer's approval. The first $2.00 (1504488) is the real purchase.
The number cannot send texts yet. Your organization's 10DLC campaign is still “submitted”, waiting on carrier approval. That is a separate process and not part of this bug.
Hard-reload the app once (Cmd+Shift+R on Mac, Ctrl+Shift+R on Windows) so your browser picks up the new build.
What you reported
On 2026-09-03 at about 01:13 UTC, in app.politogyvrm.com → SMS/MMS Blast → Phone Numbers, you clicked Purchase on +1 (541) 229-3850. After roughly 10 seconds the app said “Phone number purchase failed”. You tried again and saw “Unable to purchase the selected phone number.”
What was actually wrong
The app gave up too early. The layer that sits in front of the app allowed a purchase only 10 seconds before reporting a failure. A real purchase takes about 25 seconds: charge the card, order the number from the carrier, then register it for 10DLC. Your first purchase finished successfully in the background — carrier order 600a5946, card charged $2.00, number assigned — but you were shown “failed”.
Retrying could buy the same number twice. Nothing stopped a second purchase of a number you already owned. The retry charged your card another $2.00, then the carrier rejected the order because the number was already yours — so you saw a second error on top of a second charge.
What changed
A purchase now gets 150 seconds to finish before anything is reported, instead of 10.
If your organization already owns the number, the server returns it with $0 charged instead of buying it again.
Two purchases of the same number at the same time are refused, so a double-click cannot double-buy.
The slow “confirm campaign assignment” step no longer holds up the response.
Before showing any purchase error, the app re-checks your organization's numbers. If the number is there, it reports success — even if the response itself was lost.
Proof — your exact retry, replayed on production
We replayed the same purchase request you sent, against the live production backend, on 2026-09-03 at about 02:40 UTC. It was sent as qa-agent@politogyvrm.com, an administrator in your “We need Steve” organization, so it took the same organization and billing path as your account. We could not sign in as you — we do not have your credentials — so this is not a test from your login.
# Request (identical to Ben's retry; token redacted)
POST /purchase-phone-number
Authorization: Bearer <redacted>
Content-Type: application/json
{
"phoneNumber": "+15412293850",
"organizationId": "e80933ed-e3bb-4998-a625-103ba304c38a"
}
# Response — HTTP 200 in 0.59 s
{
"success": true,"alreadyOwned": true,"cardCharged": 0,
"totalCost": 0,
"chargeId": "127c0ace-…"
}
# Number status afterwards
+15412293850 status: assigned org: We need Steve
Before the fix this same request charged $2.00 and then returned an error. It now returns success, reports the number as already owned, and charges nothing.
Database after the replay
Check
Result
New card charges for the organization (last hour)
0
New ledger entries for the organization (last hour)