name: my-payments-api version: 1.1.0 description: > Take payments via Stripe — one-off or recurring. Connect your own Stripe account, then create hosted Stripe Checkout URLs. No raw card data ever touches your code. triggers: [payment, stripe, checkout, charge, subscription, take payments, billing, refund, recurring, sell] checksum: sha256-742d42da2441fb3ce1317b503dd68f706a1f3d4a7d0f8128473683c26fa3be18

MyPaymentsAPI

Wraps Stripe. Agents create Checkout URLs, paste them into the frontend, customers pay on Stripe-hosted pages. MyAPI never custodies funds — Stripe is the merchant of record on your connected account.

Capabilities

<!-- llm:start --> Bring your own Stripe (T0). myapi payments connect --stripe-key <sk_...> links your existing Stripe account with your own secret key. The key is validated live against Stripe, stored encrypted, and never echoed. Your Stripe account stays the merchant of record. (Connect Express / MyAPI-onboarded accounts — "T1" — are not yet available; the backend returns 501 T1_DEFERRED.)

One verb covers one-off and recurring. myapi payments charge --amount 9.99 creates a one-off Checkout URL. Add --every month (or --every year) and the same verb creates a subscription Checkout URL instead. No separate subscribe verb. --amount is in dollars (e.g. 19 or 9.99) and must be positive.

Charge returns a hosted Stripe Checkout URL. The agent sends the customer to that checkout_url — paste it into a frontend, an email, or a redirect. The card-entry surface is owned entirely by Stripe Checkout (SAQ-A scope only); MyAPI infra never touches raw card data.

Optional charge fields: --description <text> (line-item label), --email <addr> (pre-fill the customer's email), --success-url <url> / --cancel-url <url> (where Checkout redirects after the session).

Refunds are full only. myapi payments refund <charge_id> issues a full refund. Partial refunds are not supported. <!-- llm:end -->

Commands

<!-- generated:start -->

<!-- generated:end -->

Examples

<!-- llm:start -->

# ── Setup: connect your Stripe account (T0 — bring your own key) ─────────────
 
myapi payments connect --stripe-key sk_live_abcd1234...
# → Stripe connected. Your existing Stripe account stays the merchant of record.
 
myapi payments status
# → Tier / Stripe account / onboarding status
 
# ── Take a one-off payment ──────────────────────────────────────────────────
 
myapi payments charge \
  --amount 9.99 \
  --description "Pro plan upgrade" \
  --email customer@example.com
# → Charge created: pay_... — returns a hosted Stripe Checkout URL.
#   Send the customer to that checkout_url (frontend, email, redirect).
 
# ── Take a recurring payment (subscription) ────────────────────────────────
 
myapi payments charge \
  --amount 29 --every month \
  --description "Pro plan" \
  --success-url https://acme.com/thanks \
  --cancel-url https://acme.com/pricing
 
# ── Lifecycle ───────────────────────────────────────────────────────────────
 
myapi payments list
myapi payments get <charge_id>
myapi payments refund <charge_id>

<!-- llm:end -->

What's NOT available

• T1 (MyAPI-onboarded Connect Express). connect only accepts your own sk_... key today; T1 returns 501 T1_DEFERRED.
• A product catalog as a MyAPI/Stripe resource — pass --amount inline on each charge.
• Coupons, discounts, promotion codes.
• Stripe Tax integration.
• Partial refunds.
• Multi-currency on a single charge.
• Customer object as a first-class resource (Stripe tracks by email; my-crm-api has the engagement view).

HTTP (from deployed code)

<!-- http:start --> <!-- generated by npm run canonical-sync — do not edit -->

base   https://api.myapihq.com
path   POST /payments/orgs/{org_id}/connect
auth   Authorization: Bearer <key>   (fn: env.__MYAPI_KEY · container: env.MYAPI_KEY)
reply  { "success": true, "data": …, "error": null, "meta": {…} }

• Per-slot host — do not assume one host serves every slot.
• Org id goes in the PATH — there is no X-Org-Id header.

<!-- http:end -->

Run myapi payments --help or myapi payments <subcommand> --help for full flag reference.