The short answer
If your card was genuinely declined, the refusal came from your bank through Stripe, not from Whizi, so the fix is a different card or a call to your bank. Why banks block AI subscription payments in the first place, and how to tell which of the six causes you hit, is in paying for AI when your card is declined. Whizi shows no card declined message at checkout. Card details are entered on Stripe's hosted checkout page, which sits outside Whizi's codebase, so the bank's answer goes to Stripe and never reaches Whizi.
So if you saw an error with Whizi wording on it, it was not a decline. It was one of the strings below, and each one has a different cause and a different fix.
The three that are easiest to mistake for a decline:
| What you saw | What it means | What to do |
|---|---|---|
This card has already used its intro trials, so this starts at the full price of followed by a price | That card has taken the 7 day intro trial four times, the limit per card | Nothing is wrong with the card. Pay the full price shown, or use a card that still has trials left |
Pricing is temporarily unavailable. | Whizi could not read the price table from Stripe | Wait and try again later. Nothing on your side fixes this |
Failed to create Stripe checkout session. | The checkout call failed and the backend supplied no message | Retry once. If it repeats, contact support |
Every error the Whizi backend returns at checkout
These come from the server, so they arrive with an HTTP status and an error code that support can match in a network trace. Every backend error body is JSON in the shape {"error": {"code": "...", "message": "..."}}, so the code sits next to the message. The rows below are ordered by HTTP status.
| Message | HTTP | Code | Triggered when |
|---|---|---|---|
A plan and billing cycle are required. | 400 | invalid_checkout_request | The checkout body could not be parsed |
Invalid plan or billing cycle. | 400 | invalid_plan_or_cycle | The plan or cycle does not map to a known Stripe price |
No subscription item found for the active subscription. | 400 | subscription_item_missing | An in place plan change ran against a subscription with no item on it |
The supplied discount must be an active 100% promotion code or coupon ID. | 400 | invalid_discount | The code supplied is not an active 100 percent promotion code or coupon ID |
Temporary email addresses are not allowed. Please use a permanent email address. | 400 | disposable_email_blocked | The signed in account's email is on the disposable domain list |
User not found. | 404 | not_found | The checkout route could not read your user row |
Pricing is temporarily unavailable. | 503 | pricing_unavailable | The localized price table could not be read from Stripe |
What to do with each. A card that has used its intro trials is not refused at all, and has its own section below. Pricing is temporarily unavailable. is server side: HTTP 503, returned when the localized price table cannot be read from Stripe, and there is no setting on your account that changes it. Failed to create Stripe checkout session. is not a server message at all, which is why it names no reason: it is the website's own fallback text, shown when the checkout call fails and the backend supplied no message. Both are wait and retry.
A plan and billing cycle are required. and Invalid plan or billing cycle. both mean the request did not carry a plan the server recognises, so start again from the pricing page and pick the plan and the monthly or annual toggle there rather than reusing an old or edited checkout link.
User not found. means your session points at a user row the server cannot read. Sign out, sign back in, then start checkout again.
No subscription item found for the active subscription. fires during a plan change rather than a first purchase, and it is not fixable from the interface. Contact support.
Errors the website shows before checkout even opens
These come from the browser, not the server, so they have no HTTP code. They all mean the same broad thing: something failed while Whizi was preparing your account for the handoff to Stripe, so no charge was ever attempted.
| Message | Triggered when |
|---|---|
Failed to create Stripe checkout session. | The checkout call failed and the backend supplied no message |
Could not open checkout. Please try again. | The upgrade modal's checkout call threw with no message |
Authentication failed. Please sign in again. | The token fetch returned nothing before checkout |
Failed to save user before checkout. | The pre checkout user save call was not OK |
Could not prepare your account for checkout. | The pricing page could not save the user before checkout |
Missing user or Stripe customer details. | The user id was absent at checkout time |
Checkout response did not include a Stripe URL. | Checkout succeeded but returned neither a URL nor a subscription id |
Something went wrong while starting your trial. Please try again. | The pricing page's generic trial start failure |
For anything on this list, sign out, sign back in, and start checkout again from the pricing page. That clears the cases where the token fetch returned nothing before checkout, which is what Authentication failed. Please sign in again. reports.
Checkout response did not include a Stripe URL. is the exception: it means the call succeeded. Before you try to pay again, open your account settings and check whether a subscription is already there.
Two more appear on the sign in and sign up pages when you pick a plan first and authenticate second: Signed in, but checkout could not start. Please choose your plan again. and Your account was created, but checkout could not start. Please sign in and choose your plan again. Both mean the account part worked and only the handoff failed. Your account exists. Go to pricing and pick the plan again.
One last cause of a mysterious failure: retrying checkout many times in a row can trip the rate limiter, which returns HTTP 429 and Too many requests. Please wait and try again. Every request on the account, whatever the route, counts against a ceiling of 30 per minute. Wait a minute rather than clicking again.
When a card has used its intro trials
Each card can take the 7 day intro trial up to four times. The count follows the card fingerprint rather than the account, so opening a new account with the same card does not reset it.
Once a card reaches that limit, checkout is not refused. It opens at the full price of the plan you picked, and Stripe's page says so above the pay button: This card has already used its intro trials, so this starts at the full price of followed by the plan's price. Paying there starts the plan at once, with no trial week.
It is not a decline, and no retry changes it, because the count is already stored against the card. For a card that still has trials left, the intro costs $0.99 on Starter, $1.99 on Pro and $4.99 on Powerhouse in USD.
Your two options: pay the full price shown, or pay with a card that has not used its trials.
Plan prices, the trial terms and what happens at conversion are all in billing, trials and how to cancel.
Payment went through but the account is still on the free plan
A charged card plus an account that still behaves as free is a different symptom from checkout failing, and it has its own page.
Read you paid but the plan features are still locked for the strings that appear in that state, the check that tells you which account holds the subscription, and what to send support.
What Whizi cannot tell you
Three gaps, so you do not spend time hunting for answers that are not there.
Whizi never sees why your bank declined a card, because that exchange happens on Stripe's hosted checkout page, outside Whizi's codebase. So a checkout decline leaves no reason stored in your account, no retry button, and nothing for Whizi to override. The reason sits with your bank.
A failed renewal is different, and Whizi does tell you about it. You get an email naming the plan, the amount and, when Stripe kept one, the bank's reason, and a red banner at the top of the chat offers to update the card or keep going on a cheaper plan at its price. Subscriptions bought in the iOS or Android app renew through Apple or Google, which handle their own failed payments.
Whizi billing runs through Stripe, so which cards can pay at all is decided there rather than in Whizi. A Russian or Iranian card cannot complete registration. Ukraine, Kazakhstan, Turkey, Indonesia and India work end to end.
- A real card decline comes from your bank through Stripe, not from Whizi
- At checkout, Whizi has no card declined message and no decline reason to show you
- Whizi wording on the error means it was not a decline
- Session errors clear by signing out and back in, then retrying from pricing
- Pricing is temporarily unavailable is server side: wait, do not retry in a loop
- A card takes up to four intro trials, then checkout charges full price instead of refusing
- Charged but still on the free plan is a different symptom, covered in subscription-not-active
Frequently asked questions
Why does Whizi say my payment failed but my bank shows no attempt?
Because the string you saw was raised by the website before Stripe was ever reached, so no charge was attempted. The quick way to tell one of those apart from a real backend refusal: a backend refusal arrives as JSON carrying an error code, such as pricing_unavailable or invalid_plan_or_cycle, and shows an HTTP status in a network trace. A browser-side string has neither. If what you saw carried no code, nothing reached your bank.
What does This card has already used its intro trials mean at checkout?
This card has already used its intro trials mean at checkout?It means the card has taken the 7 day intro trial four times, the limit per card, so this checkout starts the plan at its full price with no trial week. It is not a decline and not an error, and the count follows the card to any account. Pay the full price shown, or use a card that still has trials left.
I got Pricing is temporarily unavailable. Is my card the problem?
Pricing is temporarily unavailable. Is my card the problem?No. It is HTTP 503 pricing_unavailable, and it comes from the route that reads the localized price table from Stripe, not from the checkout route that would take a card. There is no fix on your side, so wait rather than trying a different card. If you saw Failed to create Stripe checkout session. instead, that is a separate string with a separate origin: the website's fallback when the checkout call failed and the backend supplied no message.
My promo code was rejected. Why?
Checkout returns The supplied discount must be an active 100% promotion code or coupon ID. as HTTP 400 invalid_discount. The discount field at checkout only accepts an active 100 percent promotion code or coupon ID, so an expired code or a partial discount code will be refused there. Remove it and check out at the normal price if you need access now.
Whizi rejected my email at checkout. What happened?
You saw Temporary email addresses are not allowed. Please use a permanent email address. The checkout route returns it as HTTP 400 disposable_email_blocked when the signed in account's email domain is on the disposable list. The same string is used at sign up as HTTP 403. Use a permanent address on the account and checkout will proceed.
I was charged twice. What should I do?
Contact support with both Stripe receipts rather than cancelling blindly. Cancelling is a separate action with its own outcome: for an active subscription the cancel route answers Subscription cancellation scheduled for end of billing period., so that subscription runs to the end of the period it is already paid for.
