Access Delivery and Fulfillment

This page is for the awkward gap between "I paid for access" and "I can actually see it where I expected in TradingView."

That gap is real. A product can be attached to your Axiom account while the separate TradingView delivery work is still open, queued, failed, or waiting on the right username. The Access page is where you check that delivery work. It is not the purchase receipt page, and it is not a promise that every state changes instantly. It is the place to see what Axiom is trying to deliver, where it is trying to send it, and whether anything needs your attention.

Use this page when you want to know whether to wait, fix your TradingView username, use Retry, compare your Products page, or contact support with enough detail for someone to actually investigate.

Before you use Access

Start with the boring checks first. They save a lot of false alarms.

• Sign in to the same Axiom customer account that owns the purchase or subscription.

• Make sure your TradingView username is saved on Account.

• If you just checked out, changed a username, or changed access, give the dashboard state room to catch up before assuming the worst.

• If you are trying to compare "what I own" against "what TradingView received," keep Products open nearby.

The most important distinction is this: Products shows product or package access connected to your Axiom account. Access shows the TradingView grant or revoke work attached to that access.

Those two things belong together, but they are not the same fact.

If you are coming straight from checkout, do not treat the first stale-looking screen as the final truth. Check Products to see whether the product or package is attached to your signed-in Axiom account. Then check Access to see whether TradingView delivery work exists, is still open, completed, or needs attention.

What you should know when you are done

After a clean pass through this page, you should be able to say one of these without guessing:

• The active TradingView username is correct, and access delivery is still open.

• The active TradingView username is missing or wrong, so Account is the next stop.

• The access task completed, and the next check belongs inside TradingView.

• The task failed, and Retry is available.

• The task failed, Retry is not available, and support should investigate.

• Products and Access are showing different parts of the same story, so you need to compare them before drawing a conclusion.

That is the job here: get from a vague "something is wrong" feeling to a visible state you can act on.

Start with the Access summary

At the top of Access, use the summary cards as your first scan.

TradingView username

This shows the active TradingView username Axiom is using for delivery. If it says Not set, the next useful step is not staring harder at the task list. Go to Account, enter the correct TradingView username in the Username field, and use Save username.

If the username is set but wrong, fix it before you interpret the rest of the page or use Retry. A wrong active username can make the whole delivery story look broken even when the purchase itself is fine.

Open access tasks

This is the count of delivery work that is not finished yet. In this page, open work means tasks in Approved, Queued, or In progress state.

Open does not mean failed. It means the work has not reached its finished state yet. Do not read this card as a countdown or a delivery guarantee.

Needs attention

This counts failed access tasks. A failed task needs inspection. Sometimes there is a customer-safe next step, like correcting a username and using Retry when the button appears. Sometimes the row is telling you support needs to look at it.

Failed does not automatically mean you did something wrong. It means the current delivery attempt did not complete cleanly.

Check the TradingView username

The Access profile gives you a little more context:

• Active username is the username new delivery work is trying to use.

• Saved usernames is a count of usernames saved on the account.

• Access events is the count of visible access tasks.

The field that matters most is Active username.

Saved usernames can be useful context, but do not let it distract you. A saved username history is not the same as delivery being aimed at the right username today.

If Active username is Not set, go to Account. The Account page shows Active TradingView username and includes the username form. Enter the username exactly as it appears on TradingView, then select Save username. While it is saving, the button may show Saving....

If you change the active username, Axiom may need to re-sync access delivery for your active products. That can make older open tasks fail as superseded and create fresh delivery work for the new username. That is not the same thing as losing the purchase. It means the delivery route changed, and the Access page is recording that change.

After saving a username, return to Access and read the task list again from the top.

Read an access task row

Each row in the Access list is one delivery request. Read it like a small work order, not like a generic notification.

If there are several rows, match the row to the product name, action, status, and Requested time before deciding what it means. This matters after checkout, after a username change, and after a retry, because an older failed row can sit next to newer delivery work.

Some rows do not have every field or button. That absence is information. For example, if a failed task does not show Retry, the page is not giving you a supported self-serve retry for that row.

What each task state means

Approved

Approved means the task is open delivery work. It has not completed yet. You should usually check that the active TradingView username is correct, then watch the task move instead of treating it as a failure.

Queued

Queued means the task is waiting in the access process. If the Queue field shows a number of jobs ahead, read it as position context, not a promised clock. The page does not show a guaranteed wait time.

In progress

In progress means the task is actively being worked. Keep the active username in mind. If the username is wrong, delivery can still be aimed at the wrong place.

Completed

Completed means that access task finished in Axiom's delivery system.

Still check TradingView normally. A completed delivery task is not the same as a guarantee that you are already looking at the right TradingView script, chart, invite area, or account screen. It tells you the Axiom-side delivery task reached completion.

Failed

Failed means the row needs attention. Read the failure message, check the active username, and look for Retry.

If the failure message indicates an older task was superseded after a TradingView username update, treat that as a clue: the old delivery route may no longer be the one that matters. Check whether a newer task exists for the current active username.

If the failed task has no Retry button, do not keep hunting for a hidden self-serve action. Read the row's reason text and contact support when the visible state does not give you a safe next step.

Products versus TradingView delivery

This is the part that causes the most understandable panic.

Products and Access are answering different questions.

Products helps answer:

• What products or packages are attached to my Axiom account?

• Is this access recurring or lifetime?

• Does the product row look Active, Pending access, Ending, or Ended?

• Is there product-level delivery status such as a latest fulfillment state or pending sync?

Access helps answer:

• Which TradingView username is active for delivery?

• Are there open access tasks?

• Did a grant or revoke task complete?

• Did a task fail?

• Is Retry available?

• Does the row show a support-bound state?

So yes, you can see a product on Products while TradingView delivery is still open. You can also see Pending access or pending sync while the access task is still catching up. That is not a contradiction by itself. It is the difference between account access and delivery completion.

The reverse can also feel strange: Access may show delivery activity while Products is still settling after a purchase or subscription update. Do not use one screen alone to tell the whole story when the state is fresh. Products tells you what the account has attached. Access tells you what is happening with TradingView delivery.

Internal trial access can also create real delivery work. If Products shows Trial access, Access may show grant or revoke activity for that trial product before Billing has a paid subscription item. That does not make the delivery fake. It means the account has temporary access while the trial is still being decided. Use Trial access and conversion when the question is whether the trial should convert, expire, or show in Billing.

The clean way to read the situation is:

1. On Products, confirm the product or package you expected is attached to the signed-in Axiom account.

2. On Access, confirm the active TradingView username is the one you intended.

3. Read the task row that matches that product and the change you expected.

4. Use the task state to decide whether you are waiting, checking TradingView, retrying, or contacting support.

Do not use this page to infer refund, exchange, cancellation, or upgrade options. Those are separate workflows. This page is only about access delivery and fulfillment state.

If you just changed your username

A username change is one of the easiest places to misread the dashboard.

Use this order:

1. Open Account and confirm Active TradingView username.

2. Save the correct username if it is missing or wrong.

3. Return to Access.

4. Look for fresh delivery work tied to the product you expected.

5. Treat older failed rows as context, especially if the message says the task was superseded after the username update.

Saving a username can send active access back through delivery. It does not mean TradingView access is live the moment the form saves. The useful next check is the visible task state on Access.

When Retry is available

Use Retry only when the Access page shows the Retry button on a failed task.

That button is intentionally conditional. The page does not let every failed task be retried by the customer. The most useful self-serve retry shape is a failed delivery attempt where the active TradingView username has been corrected and the page now allows the task to be sent back into the access process.

Before pressing Retry, check:

• The active TradingView username is set.

• The active TradingView username is the one you actually use on TradingView.

• The failed row belongs to the product or package you are trying to access.

• The failure message does not already tell you support is required.

After pressing Retry, do not assume access is immediately live inside TradingView. Retrying sends the eligible task back into the access process. Watch Access for the next visible state: open, completed, or failed again.

If Retry is missing, that is not proof you broke something. It means the dashboard is not offering a customer-safe retry for that task. Use the reason text, compare Products if needed, and contact support if the state still does not explain what is happening.

If access still has not arrived

Use the visible state to choose your next move.

The goal is not to make you stare at the page until it changes. The goal is to get you to the next honest check.

When to contact support

Contact support when the website state no longer gives you a safe self-serve move.

That usually means one of these:

• A failed task does not show Retry.

• The row says Support escalation required.

• You corrected the active TradingView username, retried when the page allowed it, and the task still fails.

• Products shows product access, but Access does not explain why TradingView access is still missing.

• The active TradingView username shown on Access is not the username you expected, and you are not sure which delivery task belongs to which username.

• You see a product, package, subscription, or access row mismatch that you cannot confidently sort out from the dashboard.

Use Contact for the support handoff. The form asks for Name, Email, and Message. It can also accept an optional screenshot. If you attach a screenshot, use PNG, JPG, or WebP, and keep it under 5 MB. The form uses a verification step before sending.

Support replies by email, typically within 1-2 business days. Treat that as a real expectation, not an instant fulfillment promise.

What to send support

The best support message is boring in the right way. It gives the person reading it enough facts to reproduce the problem without guessing.

Include:

• The email address on your Axiom account.

• The active TradingView username shown on Access or Account.

• The product or package name.

• Whether you are looking at Access, Products, or both.

• The task action, such as Grant access or Revoke access.

• The task status, such as Queued, In progress, Completed, or Failed.

• The failure message, if one is visible.

• Whether Retry is visible.

• What you expected to see in TradingView.

• A screenshot of the relevant Access row, if you can include one.

Avoid sending only "access is broken." That may be true from your side, but it gives support almost nothing to work with. Send the row state, the username, and the product. That is the difference between a vague report and an investigation someone can start.

Related pages

• Dashboard

• Access

• Account

• Products

• Contact

• Trial access and conversion