# Billing Ops Edho Ferdian > >- - **Type:** Skill - **Install:** `agentstack add skill-edhoferdian-eef-billing-ops-edho-ferdian` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [edhoferdian](https://agentstack.voostack.com/s/edhoferdian) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** https://github.com/edhoferdian/EEF/tree/main/.hermes/skills/billing-ops-edho-ferdian ## Install ```sh agentstack add skill-edhoferdian-eef-billing-ops-edho-ferdian ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Billing Ops — Edho Ferdian Mode Customer billing operations and finance billing operations are consolidated into one skill per D-029 recommendation. Built ahead of its original trigger (Edho actually charging money for a shipped product) per explicit user request, D-035 — treat vendor-specific integration details (e.g. calls into a payments API) as needing re-verification once a real billing system exists, since none of this has been exercised against a live one yet. ## Where this sits - This skill covers **billing operations**: reading a billing incident, classifying it, and deciding what to do about it — customer-facing and operator-facing. - It does not own code-quality or spec-consistency review. When the question is "does the code actually enforce what we're claiming," that check is an instance of the Blueprint/Spec Consistency domain in `code-review-edho-ferdian` — cross-reference that skill for the review methodology rather than redefining it here. - It does not own the underlying payment/checkout/webhook implementation. `backend-engineering-edho-ferdian` and `data-layer-patterns-edho-ferdian` own how that code is structured; this skill only asks whether it matches what's being claimed. ## Two layers of the same problem Billing questions arrive at two altitudes, and mixing them produces bad answers: 1. **Customer-specific remediation** — one customer, one incident. What happened to them, and what's the safest fix. 2. **Operator/product truth** — is the underlying billing behavior actually what the pricing page, sales copy, or a support answer implies. This is broader than any single ticket. Always classify which layer a question is at before answering. A duplicate charge complaint (layer 1) can reveal a broken self-serve cancel flow (layer 2) — surface both, but don't let the specific incident stand in for the general claim, and don't let a general policy answer skip the specific customer's actual situation. ## Step 1 — Classify the incident (customer layer) Five categories: 1. **Duplicate subscription** — same customer billed by more than one active subscription. Confirm it's actually duplicate (same product, same customer identity) before treating it as one. 2. **Multi-seat intent vs. accidental duplicate** — what looks like a duplicate may be a deliberate second seat/license. Check stated intent and usage pattern before assuming error. Do not collapse the two. 3. **Failed or incomplete checkout** — payment attempted but never completed, or completed without provisioning the product. Distinguish "customer was never charged" from "customer was charged but not provisioned" — they need different fixes. 4. **Missing or broken self-serve control** — the customer could not do something (cancel, downgrade, update a seat count) that the product claims they can do. This is a product gap, not just a support ticket; log it as one (see Step 4). 5. **Product defect / unmet value** — the customer is billed correctly but the product itself is broken or not delivering what was paid for. This is a product-quality question wearing a billing complaint's clothes; route the underlying defect to the owning engineering skill once the billing side is resolved. Identify the customer cleanly first (matching identity, not guessing from a name or email fragment), and never expose secrets, full payment card data, or another customer's billing details while doing so. ## Step 2 — Verify the claim against the code, not the copy Never assert a billing/entitlement behavior — "it's per-seat," "quota resets monthly," "cancel takes effect immediately" — on the strength of the pricing page, onboarding copy, or a past support answer alone. If the answer matters (refund decision, policy answer, escalation), trace it to the code path that is supposed to enforce it: - checkout / plan-selection logic - entitlement or quota calculation - seat counting (does adding a checkout quantity actually change what the account can do, or does it stop at "quantity purchased") - self-serve billing-portal actions (cancel, downgrade, seat change) Do not say a behavior is "per-seat" (or any other specific billing model) unless the entitlement path in the code actually enforces it — a checkout line item is not proof of enforcement. This is the billing-domain instance of ground-truth-over-narrative: verify against what the code does, not what the page says it does. Where this check turns into a full review of the enforcement code itself, hand it to `code-review-edho-ferdian`'s Blueprint/Spec Consistency domain rather than re-deriving that methodology here. Also don't assume a duplicate subscription implies duplicate value received — a duplicate charge and a duplicate benefit are different claims, and a refund decision should be based on which one actually happened. ## Step 3 — Diagnosis is not execution This skill produces a diagnosis and a recommended action. It does not execute financial changes on its own authority. **Hard rule, consistent with the global "Explicit permission required" action category for purchase/payment operations:** refunds, credits, subscription cancellations, and any other financial adjustment are EXPLICIT-PERMISSION-REQUIRED actions. State the diagnosis, state the recommended action and its revenue impact, and get the user's explicit go-ahead before anything gets executed — a support-style script drafted for the user, not a payment sent on their behalf. Never treat "the customer is clearly right" or "this is obviously a duplicate" as authorization to skip that confirmation. Prefer the safest reversible action when a fix is warranted, and prefer whatever billing platform the ecosystem already has connected over building a custom workaround. ## Step 4 — Close with a structured handoff Every billing incident response ends with: ```text SNAPSHOT - data source and its timestamp (live vs. last-known/saved — always say which; never present a stale snapshot as current) - relevant subscription/charge/refund state CUSTOMER IMPACT - who is affected, what happened to them specifically PRODUCT TRUTH - what the code actually enforces (from Step 2) - what the pricing page / sales copy / prior support answer claims - flag any gap between the two explicitly RECOMMENDED ACTION - refund / credit / preserve / convert / no-op - marked EXPLICIT PERMISSION REQUIRED if it involves money moving or a subscription being changed — not yet executed PRODUCT GAP - the exact follow-up item to build or fix, if Step 1 or Step 2 surfaced one (e.g. a broken self-serve control, an unenforced pricing claim) ``` ## Pitfalls - Treating a stale/cached billing snapshot as live data without saying so. - Answering a pricing/entitlement question from memory or from marketing copy instead of tracing the enforcing code path. - Letting "this looks like an obvious refund" skip the explicit-permission step — obviousness is not authorization. - Conflating failed/incomplete checkout attempts with actual net revenue. - Jumping straight from diagnosis to a financial action without separating customer impact from the broader product-truth question. ## Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract) Communication to the user in Bahasa Indonesia; the structured handoff report (Snapshot/Customer Impact/Product Truth/Recommended Action/Product Gap) in English, since it gets pasted into an issue tracker or handed to another skill. Full contract: `skill-authoring-edho-ferdian` §7. - Comparing competitor pricing from memory when the ecosystem has research tooling available to check current evidence instead. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** [edhoferdian/EEF](https://github.com/edhoferdian/EEF) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-edhoferdian-eef-billing-ops-edho-ferdian - Seller: https://agentstack.voostack.com/s/edhoferdian - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.