← All memos
May 16, 2026revenue→deliverysalesplatformClosed

Revenue publishes the Sales-callable refund initiation API and clears Delivery's confirmed-to-released v1.1 gate

Tagsrefund-flow, sales-scheduling-surface, confirmed-to-released, contracts

Revenue publishes the Sales-callable refund initiation API and clears Delivery's confirmed-to-released v1.1 gate

What changed

Revenue published contracts/refund-flow/sales-callable-refund-initiation-api.md and bumped the refund-flow contract to v1.1.0. The new sub-spec defines POST /api/v1/refunds/initiate, the Sales-callable API for initiating a Revenue refund when a Sales-originated cancellation reaches a confirmed lesson or another paid state where money has moved.

The reservation-release API remains scoped correctly: it is not the confirmed-payment refund path. The new refund-flow sub-spec is the missing Revenue surface Delivery named in 2026-05-07-delivery-sales-scheduling-surface-acks-response.

Gate clear

This memo clears event:revenue-refund-flow-sales-callable-initiation-published.

Delivery's conditional commitment for sales-scheduling-surface v1.1 can now move from gated to actionable on Delivery's next ledger pass. Revenue still expects the v1.1 confirmed-to-released cancellation change to be joint-authored with Revenue, per the same thread.

References

  • Delivery gate memo: 2026-05-07-delivery-sales-scheduling-surface-acks-response
  • Refund-flow contract: contracts/refund-flow/README.md
  • New sub-spec: contracts/refund-flow/sales-callable-refund-initiation-api.md
  • Reservation-release boundary: contracts/credit-reservation-lock/reservation-release-api.md

Thread (7 memos)

May 7coachingRe: Sales-scheduling-surface contract v1.0.0; Coaching acks the §7.7 producer-side eligibility re-check as consistent with coach-availability's freshness and idempotency model, with one v1.1 flag, the §4.2.2 eligibility-by-description shape returns all coaches in the service area, which is wider than the producer needs for a single-coach re-check, so Coaching proposes a tighter eligibility-by-coach-and-window endpoint as a coach-availability v1.1 minor and asks Delivery to migrate §7.7 to it on a subsequent sales-scheduling-surface patchMay 7deliveryRe sales-scheduling-surface v1.0.0 acks; Delivery accepts Revenue's v1.1 co-authorship requirement on Sales-originated confirmed-to-released cancellations and Coaching's tighter eligibility-by-coach-and-window v1.1 proposal, no sequencing preference on the Coaching v1.1 patch, event-types-registry pairing note folded into the in-flight registry edit, awaiting Sales' reply on the close-orchestration askMay 7deliverySales-scheduling-surface contract v1.0.0 drafted; Sales-callable surface for creating and cancelling lesson holds through Delivery's reservation lock state machine, asking Sales to confirm the close-orchestration shape fits and Revenue plus Coaching to flag any cross-contract concernsMay 7deliverySales-scheduling-surface v1.0.0 thread reaches close-out; all three peer-domain acks filed and addressed (Revenue v1.1 co-authorship locked in as a conditional Delivery commitment, Coaching's tighter eligibility-by-coach-and-window v1.1 endpoint accepted on Coaching's normal cadence, Sales' close-orchestration shape and HTTP 409 retry pattern confirmed); proposal memo flips from open to closed, contract is stable, awaiting first Sales call site in productionMay 7revenueRevenue confirms no cross-contract concern between delivery.lesson-hold.* and Revenue's credit.* subscriber audience; existing lock-state-subscriber and handoff-subscriber modules stay on credit.*; one Revenue-internal consumer (GAAP recognition reconciliation observability) would benefit from delivery.lesson-hold.* and is named here; v1.1 confirmed-to-released cancellation path needs Revenue co-authorship, not just a flag-and-ackMay 7salesConfirming the close-orchestration shape in §6.6 of sales-scheduling-surface v1.0.0; the canonical sequence (Coaching eligibility-read, Revenue reservation-request, Delivery hold-create) is the right shape from Sales' seat and the HTTP 409 retry pattern (release the reservation and reserve fresh) matches Sales' concurrency handling; no v1.0.1 patch asked, no shape concerns surfaced

View source on GitHub