Verify a Stripe refund before closing the ticket

The most common high-stakes flow for a support agent is two actions in a row: issue a refund in Stripe, then resolve the Zendesk ticket and tell the customer their money is on the way. It’s also where silent failure hurts most, because the customer hears “done” the moment the agent thinks it’s done.

The failure looks like this: the agent calls Stripe, gets a response that reads like success, closes the ticket, and sends the confirmation. But the refund didn’t actually settle, a declined call, a retry that duplicated it, a stale id. The customer has now been told something false, and you find out at the chargeback.

Put a gate before “done”

The fix is one deterministic check between the action and the confirmation. After the agent issues the refund, ask Postcept whether Stripe agrees, before closing the ticket or messaging the customer.

curl https://api.postcept.com/v1/verifications \
  -H "Authorization: Bearer pcpt_sk_..." \
  -H "Content-Type: application/json" \
  -d '{
    "operation_id": "op_refund_8F31",
    "agent_id": "SupportAgent-04",
    "connector": "stripe",
    "claim": {
      "refund_id": "re_4md82k",
      "amount_cents": 12000,
      "currency": "usd",
      "customer": "mara.ellis@example.com"
    }
  }'

Postcept resolves the refund in Stripe and checks the postconditions: it exists, the amount and currency match, the customer matches, and it isn’t a duplicate. A clean run comes back verified, sealed in a signed receipt.

Branch on the result

Now the agent’s “done” is conditional on reality, not on its own report:

const v = await postcept.verifications.create({
  operation_id,
  agent_id,
  connector: "stripe",
  claim,
});

if (v.result === "verified") {
  await zendesk.closeTicket(ticketId);          // safe to confirm
  await notifyCustomer("Your refund is on the way.");
} else {
  await routeToReview(v);                        // hold, don't tell the customer yet
}

A verified result means it’s safe to close the ticket and message the customer, with the receipt as your audit trail. A mismatched, incomplete, or duplicated result holds the confirmation and routes the case to review, the customer never hears a false “done.” A 503 just means Stripe was briefly unreachable, so you retry rather than escalate.

The same gate, anywhere money or trust moves

It’s the same shape for a cancellation, a credit, or a ticket state: verify against the system of record before anyone is told it happened. Fifteen systems are supported, across payments, support, commerce, and accounting. The agent still does the work, Postcept just makes sure “done” is true before a customer relies on it.

Five minutes to try it end to end, no system to connect: the quickstart runs the whole flow in sandbox mode, including verifying the signed receipt yourself.