Flow
Where my test label went, before and after
1First try: vendor ID field
Held my readable label. The vendor needs a number there, so it said no.
2First try: my reference field
Held the same label. That part was fine.
3Second try: vendor ID field
Left out. The vendor filled in its own number.
4Second try: my fields
The label stays in my reference field. The email stays on the test-only domain.
The first real write to the vendor's sandbox bounced, and it bounced on a field I had no business filling in. The safety setup did its job. The mistake was in what I sent.
Two services, and neither trusts the browser
The ordering system has an admin page that asks the gateway to run a test write in the vendor's sandbox. The page sends almost nothing: an action from a short list, a dry-run flag that has to be a real yes or no, and an email for lookups. If the dry-run flag is missing, the request fails. That way a forgotten value can't turn into a real write.
The server adds the important parts: the write key, the store, a header saying "I really mean to write", a request ID, and a scrambled version of who clicked. A dry run stops before anything leaves my system.
The gateway checks everything again. It has its own write key, separate from the normal read key. That key works from one address, talks to one sandbox account, and expires in a few days. Before the first write, I tried the wrong key, a missing header, the wrong store, the wrong address, and a call with no login. All of them got turned away.
The ledger row that caught it
The gateway writes a row in a log before it calls the vendor. The row says sent right before the call, then succeeded or failed afterward, with the vendor's status and a short note.
One label, two slots
The test customer gets a fake name, a fake address, an email on a test-only domain, and a readable label with the day and the run's ID. I put that label in two fields. One was the vendor's reference field, which seems to be there for callers to store their own ID. The other was the vendor's own ID field.
The vendor said no, because its ID field has to be a number. The log row said failed, and no customer was created.
Deleting the line
I deleted one line, so the payload stops sending the vendor's ID. The vendor picks its own number now. My label lives in the reference field, and the email keeps its test prefix. The next try worked. A test checks the outgoing request: no vendor ID field, test prefixes still in place, and only the sandbox account allowed.
The test body now leaves out the vendor's ID.
The test record carries only my own label and a reserved test email address with the run label in it, and nothing the vendor mints.
A lookup that couldn't find anything I made
I'd built the lookup earlier. At first it searched for an address it invented on every call, so it could never find my test customer. Now it also takes an address from the caller, but only a test address on the test domain. A normal email gets rejected, and there are tests for both cases. The lookup found exactly one match, and the log row said succeeded.
One sandbox, one good create
This was one bad try, one good try, and one lookup. It shows the path works once and that a failure gets logged without writing anything. I asked the vendor to keep its duplicate check on, but I never sent the same customer twice, so what happens on a repeat is still a guess.