Introduction

Use [Contact](https://www.axiomcharts.com/contact) when you need a human to help with a question the website cannot settle for you.

Written By Axiom Admin

Last updated 22 days ago

Contact and support

Use Contact when you need a human to help with a question the website cannot settle for you.

That sounds simple until you are in the annoying part: you paid and access is not where you expected, Billing looks empty even though you have a receipt, a refund row says review is needed, or an exchange flow is waiting on something you cannot see. In that moment, the useful move is not to guess harder. It is to check the page that owns the state, then send support the few facts that let someone trace what happened.

Contact is not a shortcut around the dashboard or the policy pages. It is the handoff when the dashboard, receipt, access state, or policy path still leaves a real question.

Before you write support

You can use Contact without signing in. If your question is general, that may be enough.

If the issue is tied to a purchase, access, billing, refund, exchange, or dashboard state, sign in to the Axiom account tied to the purchase email before you start checking. The public form can still receive your message, but the dashboard gives you better evidence than memory does.

Have these nearby when they apply:

The email address used at checkout.
Your Axiom account email, if it is different from the email you want support to reply to.
The product or package name.
Your TradingView username, for access issues.
Any Paddle receipt, transaction date, subscription context, or visible Billing status.
The source product, target product, target term, amount due, exchange credit, or exchange status, for exchange questions.
A screenshot if the problem is visible and the image fits the form limits.

If you cannot sign in or cannot reach the dashboard page you need, say that plainly in the message. That is still useful information. Include the purchase email and what you were trying to check, so support is not starting from a blank room.

Do not send passwords, full card numbers, private TradingView credentials, secrets, or anything support does not need to identify the account state.

Decide what to check first

Use Contact first when you have a general product question, an unclear policy question, a support question that is not tied to a signed-in account state, or a dashboard page specifically points you toward support.

Check the dashboard first when the question depends on what your account can currently see.

If the problem is about	Check first
TradingView access, username routing, failed delivery, or a missing retry path	Access
Which products or packages appear on your account	Products
Subscription rows, payment history, refund rows, or refund submission states	Billing
Same-cadence exchanges, lifetime exchanges, term upgrades, or recent exchange activity	Exchanges
Refund terms, duplicate charges, billing errors, or access issues after purchase	Refund Policy
What exchanges and upgrades mean, and when manual review may be needed	Exchange Policy

The point is not to make you do homework before you are allowed to ask for help. The point is to avoid a support thread that starts with everyone guessing.

What support can and cannot do from Contact

Support can help review a confusing account state, a visible error, a missing access result, a billing or refund question, or an exchange flow that has moved out of clean self-serve territory.

Support cannot make every state instant. Contact does not guarantee immediate TradingView access, immediate Paddle sync, instant refund completion, instant exchange completion, or a policy override. If a dashboard button is visible, that self-serve action is usually the cleanest first move. If the button is missing, failed, unavailable, or the page tells you to contact support, send the visible state instead of trying to force a hidden path.

That boundary matters because a lot of support confusion comes from treating every problem like the same kind of problem. A failed access task, an empty payment history, a submitted refund request, and a waiting exchange confirmation need different evidence.

If the issue is access

Open Access before writing support if the issue involves TradingView delivery.

Look at the summary first:

TradingView username shows the active username Axiom is using for delivery. If it says Not set, that is a real clue.
Open access tasks points to access work that is not finished yet.
Needs attention points to failed access work.

Then read the matching access row. A row can show the task action, product name, requested time, attempt count, queue state, failure message, status, and actions.

Common access states need different reactions:

What you see	How to read it
`Approved`, `Queued`, or `In progress`	Access work is open. Confirm the active TradingView username and avoid inventing extra retry steps.
`Completed`	The Axiom-side delivery task finished. If TradingView still looks wrong, check that you are looking at the right TradingView account and use `Open TradingView` if the row shows it.
`Failed` with `Retry`	The row is offering a customer-side retry. Confirm the username first, then use `Retry` if the button is visible.
`Failed` without `Retry`	The dashboard is not offering a customer-side retry for that task. Read the visible reason and send support the row details.

If TradingView username says Not set, go to Account and add the username Axiom should use for delivery, then come back to Access and read the task list again. Saving a username fixes the delivery destination. It does not mean TradingView access appears the second you save it.

For access support, include:

The Axiom account email.
The product or package name.
The active TradingView username shown on Access.
Whether the username says Not set.
The task status, such as Queued, In progress, Completed, or Failed.
Whether Retry appears.
Any visible failure message.
A screenshot of the relevant access row, if that is easier than explaining it.

Do not write only "access is broken" if you can avoid it. That may be exactly how it feels, but support needs the username, product, task state, and visible failure text to start in the right place.

If the issue is billing or a refund

Open Billing before writing support if the question involves a subscription, payment, receipt, or refund state.

Billing has three tabs:

Subscriptions
Payment history
Refunds

Read empty states carefully:

No subscriptions means no monthly or yearly subscription records are visible in that account view.
No payments yet means no completed Paddle transactions are visible there after synced events.
No refund-eligible purchases means the Refunds tab does not currently show a one-time purchase inside the self-serve refund window.

Those states do not prove by themselves that no charge happened, especially when you have a Paddle receipt, checkout just finished, or you may be signed into a different account from the one used at purchase.

If the Refunds tab shows Request refund, that button submits a refund request for the visible row. It does not mean the refund is already approved or finished. The final refund state is confirmed by Paddle.

If Billing shows Review needed, Contact support, or says automatic refund submission failed, support is the right handoff. Keep the Refund Policy open too. The policy is where refund terms live; Contact is where you send the specific account state for review.

For billing or refund support, include:

The purchase email.
The Axiom account email, if different.
The transaction date or Paddle receipt context, if you have it.
The product or package involved.
Which Billing tab you checked: Subscriptions, Payment history, or Refunds.
The visible status or empty state.
Whether you selected Request refund.
Whether the page showed refund submitted, automatic submission failure, Review needed, or Contact support.
A short explanation of what you expected to see instead.

Support can review confusing billing and refund states. That is different from promising approval, instant sync, or a policy override.

If the issue is an exchange or term upgrade

Open Exchanges before writing support if the question is about moving value from one product or term into another.

The Exchanges page can show Exchanges and Term upgrades, same-cadence exchanges, lifetime exchanges, and recent exchange activity. Depending on the account state, option cards may show amount due, target price, exchange credit, discount applied, and source action notes.

Controls such as Apply upgrade, Start checkout, Exchange, Preview exchange, and Confirm replacement are conditional. Use them only when the dashboard shows them for your account. If an option is not shown, do not assume there is a hidden exchange path for that product.

Some exchange states are waiting states. The dashboard may say access changes are being reconciled, Paddle confirmation is still pending, payment details need finishing, or support review is needed. Those states are not all the same. Send the visible wording instead of trying to translate it.

For exchange support, include:

The source product.
The target product or target term.
Whether the option appears on Exchanges.
The amount due, exchange credit, discount, or target price shown, if visible.
Whether Paddle checkout opened.
Whether you see a payment recovery state such as Finish payment details or Finalizing subscription swap.
Any recent exchange activity status.
Any support-review or waiting-for-confirmation message.

Use the Exchange Policy for what exchanges and upgrades mean. Use Contact when the visible account state is unclear, blocked, interrupted, or pointing to review.

Fill out the Contact form

On Contact, the form asks for:

Name
Email
Company (optional)
Topic (optional)
Photo or screenshot (optional)
Message

Use Email for the address where you want the reply. If the purchase used a different email, say that in the message.

Use Topic (optional) if a short label helps, such as access, billing, refund, exchange, or product question. Leave it blank if the topic is not obvious. The message matters more than choosing the perfect category.

The message needs enough context to be useful. Very short messages can be rejected, and even when they send, they usually create more back-and-forth. A good message does not need to be polished. It just needs to include the account, product, page, visible state, what you expected, and what happened instead.

Screenshots are optional. They help when the issue is visible: an access row, billing tab, refund state, exchange option, error message, or anything that would be painful to describe. The form accepts PNG, JPG/JPEG, and WebP images up to 5 MB. If the screenshot will not upload, remove it or resize it; the form can still send without an attachment.

Use Send message when the form is ready.

Verification, rate limiting, and support chat

The Contact form and support chat can ask for verification. This is bot and abuse protection for support workflows. It is not support deciding your issue is suspicious.

If verification fails, expires, times out, or says it is required, use the visible retry path when it is available. If the page says too many contact requests were sent, wait and try again later. The public manual cannot give you a private bypass, and repeating the same failed submit usually does not make the state clearer.

The Contact page can also show support chat. Chat may be the quicker back-and-forth path when optional support tooling is enabled, but it depends on your support-tooling consent and whether the chat can open. If support tools are not enabled, the page can point you toward cookie settings. If chat does not open, keep using the Contact form. The form is still a valid support path.

After you send the message

After a successful submission, the form clears and the page tells you the message is in. Support replies by email.

The Contact page sets a normal expectation that replies are typically within 1-2 business days. Treat that as a typical response window, not an emergency-support guarantee and not a promise that access, refunds, billing records, or exchanges will complete inside that window.

If the form shows a send error, retry later or use another visible support path on the page. Do not assume a failed send means the issue itself was rejected.

If the state still feels stuck

Use the visible state to choose the next move.

What you see	What it means at the customer level	Next move
`Name is required`, `Email is required`, or an email validation error	The form cannot send without basic reply information.	Fill the missing field or correct the email address.
Message is too short	The form needs more context before it can send.	Add the page you were on, product, visible state, and what you expected.
Screenshot upload fails	The file type or size does not fit the form limits.	Use PNG, JPG/JPEG, or WebP under 5 MB, or send without the screenshot.
Verification is required, expired, failed, timed out, or not ready	The protected form or chat check did not complete cleanly.	Try the visible verification path again, or wait and retry later.
Too many contact requests were sent	The support workflow is slowing repeated submissions.	Wait before trying again. Do not keep resubmitting the same form.
Support chat does not open	Optional chat tooling may not be enabled or may not have loaded.	Use the Contact form, or adjust support-tooling consent if you want to use chat.
You have a Paddle receipt but Billing shows no payments	The signed-in account view may not have synced or may not match the purchase email.	Confirm the account and send support the receipt context if the mismatch remains.
Refund request says submitted	The request was sent, but the final refund state is not done just because the row changed.	Watch the Billing state and contact support if the visible state stops making sense.
Automatic refund submission failed	The self-serve path did not complete.	Contact support with purchase email, transaction date, product, and visible Billing state.
Access shows TradingView username as `Not set`	Axiom does not have an active username to use for delivery.	Add the correct username on Account, then re-check Access.
Access shows `Failed` with `Retry`	The dashboard is offering a customer-side retry for that failed task.	Confirm the username first, then use `Retry` if the row supports it.
Access shows `Failed` without `Retry`	The dashboard is not offering a safe self-serve retry for that row.	Send support the row status, product, username, and failure message.
Exchanges shows no eligible option	The account does not currently show that exchange path.	Check the Exchange Policy, then contact support only if the account state looks inconsistent.
Exchange flow is waiting for Paddle confirmation	The payment or confirmation side has not visibly settled yet.	Do not start guessing with unsupported actions. Send the visible status if it stays unclear.
Exchange flow says support review is needed	The dashboard is moving the case out of self-serve.	Contact support with source product, target product or term, amount due or credit, and the review message.

What to send support

Use this base shape for almost every support message:

Your name and reply email.
The Axiom account email, if different.
The product or package name.
The page you were on.
What you expected to happen.
What happened instead.
The exact visible status, button, tab, or error text that seems relevant.
A screenshot, if the state is visible and the image fits the form limits.

Then add the details that match the problem.

For access:

Active TradingView username shown on Access.
Whether it says Not set.
Access task status.
Whether Retry appears.
Any failure message.
Product name shown on the task, if present.

For billing or refunds:

Purchase email.
Transaction date or Paddle receipt context.
Billing tab checked: Subscriptions, Payment history, or Refunds.
Visible status or empty state.
Whether you clicked Request refund.
Whether the page showed refund submitted, automatic failure, Review needed, or Contact support.

For trial access:

The trial product or package name.
Whether Products shows Trial access, Keep after trial, View trial, or Confirm keep after trial.
The trial status and trial end date from the trial detail page, if available.
Whether Billing shows a paid subscription item yet.
What Access shows for TradingView delivery, if the trial product needs TradingView access.
Any trial-related email subject or approximate email time.

For exchanges:

Source product.
Target product or target term.
Whether the option appears.
Amount due, exchange credit, discount, or target price shown.
Whether Paddle checkout opened.
Recent exchange activity status.
Any payment recovery, waiting, or support-review message.

You are not trying to sound like a support professional. You are trying to give the person reading your message a clean starting point. Account, product, visible state, expected result, actual result. That is enough to move from "something is wrong" to "here is the thing to investigate."