Skip to content
AskVault Docs
Try Free →

Stripe integration use cases

Written by , Principal Architect, Networks and Tech, AskVault · Reviewed by Allison Chan
Last updated: · 5 min read

Why identity verification is mandatory

Billing data is sensitive: dates, amounts, last-4 of cards. Anyone could claim to be a customer and ask about their account if the bot trusted self-reported identity.

The subscription_manager skill refuses to act unless the visitor is verified via HMAC (identity verification setup). For anonymous visitors asking billing questions, the bot escalates to a human agent rather than risking impersonation.

Setup requires the Stripe integration plus identity verification (about 15 minutes extra).

1. What subscription_manager is not — a status lookup tool

Common billing questions customers ask ("when does my subscription renew?", "what plan am I on?") aren't answered by a dedicated live-lookup tool today. subscription_manager looks up the visitor's Stripe subscription internally to confirm ownership, but only as a step inside an upgrade, downgrade, or refund action — it doesn't expose subscription details (plan, renewal date, invoice amount) back to the model as a standalone answer. For a pure status question, route to escalate_to_human or your own indexed billing FAQ content until a dedicated lookup path exists.

2. Refund processing within policy bounds

For refunds within your defined policy (e.g., within 14 days of charge, less than $500), the bot can process directly:

  1. Customer requests refund.
  2. Skill checks policy bounds: within window? amount within auto-approve cap?
  3. If yes, refund issues via Stripe Refunds API. Customer gets confirmation within 30 seconds.
  4. If outside bounds, escalates to a human with full context.

Auto-refund cap defaults to $500 per visitor; configure under Skills > subscription_manager > Refund Bounds. Higher caps require admin approval.

About 60 to 70% of refund requests fall within auto-approve bounds. Saves about 5 to 10 minutes of human-agent time per ticket.

3. Plan changes

Customers upgrade or downgrade via chat:

"I want to upgrade from Starter to Growth."

The flow:

  1. Identity verified.
  2. Customer (or your prompt/config) supplies the target Stripe Price ID — there's no live pull of your Stripe Products catalog into the conversation today, so the bot needs that price id available from context or configuration.
  3. Customer confirms.
  4. Stripe Subscription updated via Stripe's subscription-update API, with Stripe's default proration behavior.
  5. Confirmation sent with the resulting status.

Useful for self-service upgrades that previously required sales contact, once the price IDs your bot should offer are wired into its prompt or a skill config.

Note on downgrades. Every downgrade requires a written policy match before it executes — configure what your team allows to downgrade under written policy, or it's blocked and escalates.

4. What this integration does not do (yet)

To set expectations correctly:

  • No automated failed-payment outreach. AskVault's Stripe webhook receiver verifies the signature and logs the event, but doesn't yet act on invoice.payment_failed — no automatic WhatsApp/email nudge is sent.
  • No invoice retrieval. There's no skill that lists a customer's past invoices or returns PDF links; the underlying single-invoice lookup method exists in code but isn't wired into any skill yet.
  • No live subscription-status Q&A. See use case 1 above — subscription_manager only exposes upgrade/downgrade/refund, not a plain status answer.
  • No audience-tag sync from Stripe events. Subscription and invoice webhooks are received and verified, but nothing currently updates AskVault audience tags or CRM records from them.

If your use case depends on any of these, the custom_webhook skill is the way to bridge to your own Stripe-connected backend today.

Webhook events AskVault receives

On connect, AskVault automatically registers a webhook endpoint on your Stripe account (no manual setup in Stripe Dashboard) and subscribes to:

  • customer.subscription.created
  • customer.subscription.updated
  • customer.subscription.deleted
  • invoice.paid
  • invoice.payment_failed
  • checkout.session.completed

Each event's signature is verified and the event is logged — see What this integration does not do (yet) for what happens (and doesn't) beyond that today.

Policy bounds

The subscription_manager skill has guardrails the LLM can't override:

  • Daily refund cap. A workspace-level ceiling on refund volume per day, checked before every refund.
  • Written policy match. Every refund and every downgrade is checked against a written policy before it's allowed to execute; no match means no action.
  • Idempotency. Repeated identical requests within the same window return the cached result instead of double-executing.

Configure under Skills > subscription_manager > Bounds.

Sample customer journey

End-to-end:

  1. Customer logs into your product. Widget identifies them via HMAC.
  2. Customer asks "Why was I charged twice?" and requests a refund.
  3. Bot checks the daily refund cap and written policy, then issues the refund via Stripe's Refunds API.
  4. Customer asks to upgrade. Bot confirms the target plan, then updates the Stripe subscription.

Both actions happen without human involvement, gated by the policy checks above.

Plan availability

Stripe use cases require:

  • AskVault Business or Enterprise plan. Free, Starter, Growth don't include the subscription_manager skill. Business+
  • Identity verification configured. See setup.
  • Stripe account in good standing. Stripe restrictions (high-risk merchant, missing KYC) limit some operations.

Privacy and PCI scope

Important:

  • AskVault never sees raw card numbers. All card operations happen in Stripe's PCI scope.
  • AskVault stores customer ID, subscription ID, plan name. Not card data.
  • Last-4 of card may be referenced in conversation (e.g., "your Visa ending 4242 was charged $49"). This is Stripe-provided metadata, not PCI.

AskVault is therefore outside PCI scope. Your Stripe relationship covers the PCI obligation.

Planned features (on the roadmap)

Documented for accuracy:

  • Razorpay and PayPal parity. Today, Stripe is the only payment processor AskVault can connect to a workspace for refund/plan-change skills. Customer-facing Razorpay and PayPal integrations are on the roadmap.
  • Stripe Tax integration. Today, taxes pass through. Native Tax handling in conversations planned.
  • Multi-currency display. Today, invoices show in customer's native currency from Stripe. Inline conversion in conversation planned.
  • Subscription pausing. Today, customers can cancel or change plan. Self-service pause planned.

Common pitfalls

Bot escalates every billing query. Identity verification not configured, so the bot can't verify the visitor. Set up HMAC verification.

Refunds blocked at cap. Cap set too low. Bump under Skills > subscription_manager > Refund Bounds.

Downgrade blocked. No written policy matches the requested downgrade. Add or adjust the policy so subscription_manager can match it, or the request keeps escalating to a human.

Webhook events not arriving. The endpoint AskVault auto-registered on your Stripe account was deleted or the connection needs to be re-authorized. Reconnect Stripe to re-register it — no manual Dashboard configuration should be needed.

FAQ

Can the bot process refunds for amounts above the policy cap?

No. The cap is enforced outside the model's control. Higher-amount refunds escalate to a human.

Does this work for Stripe customers in India (UPI, RuPay)?

If your Stripe account accepts those payment methods, the resulting subscriptions and charges are ordinary Stripe objects and work the same as any other — refund and plan-change actions aren't restricted by payment method.

Can I require a confirmation step before any billing action?

Yes. Under Skills > subscription_manager > Confirmation, require explicit "yes" before any refund or plan change.

What happens if Stripe API is down?

The bot detects and falls back to "I can't access billing right now; let me escalate". Stripe outages typically last under 15 minutes.

Can I see all bot-driven billing actions in an audit log?

Yes. Every action logs in Dashboard > Audit Log with timestamp, actor, customer, and outcome.

Was this page helpful?