Warming up the decks…
BlendPartner APIblendapp.aiTesting & go-live
Everything below can be rehearsed against a real event that Blend puts in your catalog at a nominal price. There is no separate sandbox to keep in sync, you test the system you will ship on.
How Blend sets you up to test
Blend adds a test event to your channel, priced low, not listed publicly. It behaves exactly like a real event: real holds, real inventory, real tickets, real emails. When you are done, Blend switches it off and it disappears from your catalog.
Verify in this order
- Credentials
GET /v1/channel/eventsreturns your catalog. If this works, your key, secret and IP allowlist are all correct. - Session
POST /v1/channel/sessionreturns a URL. Open it in a normal desktop browser first, you should see the catalog, not an error. This proves the session before any app code exists. - Webview
Load the same URL in your app. Confirm cookies persist across navigation and the seat map responds to touch.
- Bridge
Tap Pay. Your handler should receive
type: "charge"with an order id and amount. If you see “cannot take payment here” the handler was not registered before the page loaded. - Confirm
Charge, then confirm. Within a few seconds the webview should show the ticket without you refreshing it.
The failure paths, rehearse these too
A happy path that works proves very little. These are the cases that decide whether launch week is calm.
| Rehearse | How | Expected |
|---|---|---|
| Duplicate confirm | Send the same confirm twice. | Both succeed. One ticket. One email. |
| Retry after timeout | Kill the connection mid-confirm, then retry. | Second attempt succeeds; no second ticket. |
| Wrong amount | Confirm with an amount that differs from the order. | 409 AMOUNT_MISMATCH with serverTotal. |
| Bad signature | Sign 42.5 instead of 42.50. | 401 INVALID_SIGNATURE. This is the most common real bug. |
| Expired hold | Hold a seat, wait 11 minutes, then pay. | A conflict before any charge. |
| Expired session | Open a session URL after 30 minutes. | An invalid-session page. Mint a new one. |
| Reused session URL | Open the same URL twice from a cold start. | Handled, but mint one per buyer per visit rather than relying on it. |
| Event switched off | Ask Blend to disable the test event while you hold its page open. | It vanishes from the list and the detail call returns 404. |
| Abandoned payment | Reach the pay sheet, then cancel. | No charge, no ticket; the seat returns to sale on its own. |
Powered by Blend
Go-live checklist
- Secret and signing key are on the backend only, confirmed absent from the app binary.
- Confirm is called from your backend, never from the app.
- The charged amount is read server-side from Blend, not taken from the bridge message.
- The bridge message is origin-checked before it is acted on.
- An idempotency key is sent per buyer action, and reused on retry rather than regenerated.
CONFIRM_FAILEDtriggers a refund in your code, not a manual process.ACCRUAL_FAILED_RETRYtriggers a retry, with backoff.- Timeouts resolve by asking order status, never by assuming.
- Your egress IPs are on the allowlist, including any new region you deploy to.
- Someone on your side has read Errors end to end.
When you are ready
Tell Blend and the real events are added to your channel. Nothing about your code changes at go-live, the same credentials and the same endpoints serve the real catalog. Going live is a configuration change on Blend’s side, not a release on yours.