DocsRequest early access
Product
Refunds in chatVerify the customer, find the payment, resolve it.Disputes & fraud warningsPrevent chargebacks, respond to disputes on time.Refund policy & simulatorClear rules, tested before you publish.Safety & auditWhy the AI can never move money.Payment analyticsApprovals, declines and alerts at a glance.TicketsYour team’s queue after the automation.CasesEvery request with its decision, step by step.
Solutions
Subscription softwareCancellations and forgotten renewals.Online storesDouble charges, deliveries, chargebacks.Digital goods & gamesFraud warnings and refund abuse.Online educationGuarantee refunds, by chat or email.Travel & bookingsLarge amounts, decided by people.Several countriesSeveral accounts, several currencies.Payment providersStripe, PayPal, Paddle, Adyen and more.Your own payment systemOne open contract over REST or MCP.Helpdesk teamsZendesk, webhook intake and email.
Developers
The Chargeless APIWebhooksAPI referenceYour own billing systemEvidence serviceprovidercheck
Resources
How it worksFrom customer request to resolution.IntegrationsProviders, channels and helpdesks.SecurityHow money and data are protected.FAQAnswers to the common questions.
DocsPricing
Request early accessSign in
Payment analytics

See where payments fail, and when it changes.

Every card attempt by country, brand, issuer and BIN, your card-network standing, and alerts when a rate moves.

Request early accessRead the guide
Payment analytics overview: approval rate, declines, dispute rate, daily attempts and open alerts.
Illustrative example, not real data

Five views of the same payments.

Declines split by what explains them.

Pick a country, brand or decline category and every report follows. Each group is compared with the previous period.

  • Country, brand, issuer, BIN
  • Twelve decline categories
  • Volume per currency
Payment analytics, Declines: declined attempts and the decline rate per day against the previous period.
Illustrative example, not real data

Analytics that never touch a refund decision.

Attempts are for analytics only. The policy never reads them, alerts only notify, and no card number is kept.

  • Owners, admins, analysts
  • Alerts never change anything
  • Programme figures are estimates
Payment analytics, Alerts: three open alerts, each saying what moved and against what, with a button to show the payments.
Illustrative example, not real data

Frequently asked questions

Can’t find your question?

See every question merchants ask, or ask us when you request access.

All questionsRequest early access
01Does payment data influence refund decisions?

No. Payment attempts are stored for analytics only and are never used in a policy decision.

02Do you store card numbers for this analysis?

No. Only the BIN cut to its first six or eight digits, the last four digits, the card brand and your provider’s identifiers.

03Does it work with my own payment system?

Yes, if your system reports payment attempts through the optional part of the contract. The panel says clearly when it does not.

Start with low limits. Raise them when the record shows it works.

Start in test mode, run your policy against your own history, and go live when the results meet your standards.

Request early accessHow it works
  1. 1A test workspace on your provider’s test mode
  2. 2Your past requests replayed against your policy
  3. 3Live with low limits, raised as the record allows