Test refunds and cancellations against a simulated Paddle that fails on purpose. In production, COLVO holds a scoped Paddle API key, applies your limits and checks every result in Paddle.
ctm_, sub_, txn_), refunds that wait for review and no idempotency keys.refund.create payment_id (txn_…), amount_minor, currency → a Paddle refund adjustment
subscription.cancel subscription_id, mode: period_end | immediate → next_billing_period | immediately
subscription.pause subscription_id, resumes_at? → pause from the next billing period
subscription.resume subscription_id
subscription.cancel_undo subscription_id → removes the scheduled cancel
Not yet on Paddle: subscription.change_plan, coupon.apply, refunds by invoiceThe agent never holds your payment keys — it proposes, COLVO decides and executes.
Paddle approves refunds before paying out. COLVO keeps the operation open, the agent says “requested”, and it turns VERIFIED only when Paddle approves — or opens an incident if Paddle rejects it.
Paddle has no idempotency keys. COLVO tags every refund with its operation id and looks for it before any retry, so a lost response can’t become a second refund.
Paddle is the merchant of record: limits count what the customer gets back, tax included.
No — remove it. Only COLVO’s executor uses the key, encrypted per organisation.
Transactions read, Subscriptions read and write, Adjustments read and write, Customers read. Nothing else.
Not on Paddle yet — they work on Stripe. A mandate on a Paddle connection that lists them is refused.
No — Paddle Billing only (API keys starting with pdl_).
Reference: Mandates & connections · Webhooks
Test your agent before it ships — and guard every real action once it’s live. In a safe copy of your world first.