Products and access

Use Products when you need to know what the signed-in Axiom account currently has attached to it. It is the inventory page for your account. It is not the whole receipt ledger, and it is not the page that proves TradingView delivery has finished.

That sounds simple until money, subscriptions, packages, refunds, and TradingView access all start speaking at once. A product can belong to your Axiom account while TradingView delivery is still open. A package can be the thing you bought while the rows underneath it are the individual tools inside the package. A product can move into history because access ended, was refunded, was exchanged, or was revoked. None of those states should be guessed at from memory. Read the page like evidence.

The clean distinction is this:

• Products is the account inventory view. It shows current products and packages, product rows inside packages, refund state where the page supports it, and recent no-longer-active access history.

• Access is the TradingView delivery view. It shows the active TradingView username, delivery tasks, queue context, failures, Retry when the page allows it, and recent access events.

• Account is where you check or save the active TradingView username.

• Billing is where you check subscription and payment context.

Those pages are related. They are not interchangeable. Most of the panic around access starts when one page is asked to answer all four questions.

Before you read Products

Start here before you decide something is missing.

• Sign in to the same Axiom account you used at checkout. If you use more than one email or browser profile, settle that first.

• Keep the product or package name nearby.

• If the product needs TradingView access, know the TradingView username you expected Axiom to use.

• If checkout, a username change, an exchange, a refund request, or a subscription change just happened, leave room for the dashboard state to catch up before treating the first refresh as final. The dashboard does not publish a guaranteed sync timer, so compare the relevant pages instead of waiting for a clock that is not there.

• Keep Access nearby if the question is TradingView delivery.

• Keep Billing nearby if the question is a subscription, transaction, or payment record.

Wrong account is the boring failure mode, but it is also the one that wastes the most time. If you are signed into a different Axiom account than the one used at checkout, Products can be accurate and still look empty to you.

What you should know when you are done

After using this page, you should be able to say:

• which products or packages are attached to this Axiom account;

• which current records are recurring, lifetime, or access-based;

• whether a card is a standalone product or a package containing product rows;

• whether current access is Active, Pending access, or Ending;

• whether a no-longer-active record belongs in Access history;

• whether a product row has an Open TradingView link;

• whether the next check belongs on Products, Access, Account, Billing, Browse products, or Contact.

That is the job: get from "something feels off" to a visible state you can act on. If you cannot name the visible state yet, you are still gathering evidence.

Start with the summary cards

The top of Products gives you a fast scan. Use it, but do not over-trust it. The cards tell you where to look next; the detailed truth is still in the product cards, Access, Account, and Billing.

Access queue is the card people misread most easily. It does not turn Products into a delivery tracker, and it is not a timer. It means there is access work or attention state worth checking on the Access page. Open work may still be moving through Approved, Queued, or In progress. Failed work needs inspection, and sometimes a Retry or support handoff, but Products is only showing you the signal.

If the summary says there are no active items, do not stop there if you just checked out or changed access. Confirm the account, then compare Products with Billing and Access. One quiet summary card is not enough evidence to buy again, assume a refund happened, or decide TradingView delivery failed.

Read Current products

The Current products section is the main inventory area. It answers the practical question: what does this account currently have?

If the section shows No active products, the page is saying no current inventory is visible for this signed-in account right now. That can mean there truly is no active access. It can also happen while a fresh checkout, subscription, or access update is still syncing through payment and access delivery. Use Browse products if you are intentionally shopping. If you expected an existing purchase, do not use Browse products as a fix. Check the account, Billing, and Access first.

When current inventory exists, you will see product or package cards. Read each card from the top down.

Status, pricing, and kind

At the top of a card, you may see:

• a status pill, such as Active, Pending access, or Ending;

• a pricing label, such as Lifetime, Monthly, Yearly, or Access;

• a kind label, either Product or Package;

• the product or package name.

The kind label matters. A Product card usually represents one tool. A Package card can represent a bundle you bought or subscribed to, with individual product rows listed underneath it. If the card title and the rows underneath do not use the exact same name, slow down before assuming anything is wrong. The card can be the package; the rows can be the tools inside it. That is especially important when a package includes several products with different delivery states.

Source, subscription, and transaction context

A card can also show source information, a shortened subscription reference, or transaction amount. These details help explain where the current access came from, such as a lifetime purchase, monthly subscription, yearly subscription, or recurring subscription.

Use those fields as orientation. They do not replace Billing. If your real question is "what subscription is this?" or "what payment record exists?", open Billing. If a field or action is missing from a card, do not invent a policy from the absence. Follow the page that owns that question.

When a card has subscription context, it can show View subscription. Use that link to inspect the subscription detail. When a card shows Exchanges, use it only as the visible handoff into exchange-related account work. Do not infer exchange eligibility from the Products page alone.

Started, Access, and Refund

Inside a card, Started tells you when this access record began. Access gives the page's access timing context for that card. Refund shows the refund state the page can currently name for that item.

The Refund field is intentionally narrow. It may show a refund deadline, a latest refund state, a blocking reason, or that refund is not applicable. It is not the whole refund policy, and it is not a promise that every purchase can be refunded from this page.

If Request refund appears, the page is offering a self-serve refund request for that visible item state. It is a request, not a promise that the refund is final. If Contact support appears for refund review, the page is telling you the automatic path is not enough from the current information. Support review is not the same thing as guaranteed approval.

What each current status means

Read the status label as account inventory first, not as TradingView proof.

The important part is the gap between account access and delivery. Active tells you the Products page sees current account access. It does not promise TradingView has already finished showing the tool. Pending access tells you the item is not invisible to the account, but the state is not fully settled. Ending means do not assume the access is already gone until the page has moved it out of current inventory. Ended belongs to the no-longer-current story; by itself, it is context, not a verdict that something went wrong today.

Read product rows and TradingView links

Under a product or package card, the page can list product rows. These rows are where you look for the specific product name, product type, and fulfillment status.

A row can show a fulfillment status from recent access work. If the page does not have a visible fulfillment status for the row yet, it can show pending sync.

Read pending sync carefully. It does not mean "failed." It means the row does not yet have settled delivery-state text to show you. The next check is Access, not a guess. If the row belongs to a package, check the row itself, not only the package card title.

Some product rows show Open TradingView. Use it when it appears. It means that row has a TradingView product link available from the current source state.

If Open TradingView is missing, do not turn that absence into a verdict. The page does not promise every product row has a direct TradingView link. Missing Open TradingView does not prove you lack account access, and it does not prove the purchase failed. Check the card status, then use Access and Account to inspect delivery and username state.

Read Access history

Access history is for recent product access records that are no longer active.

The table can show:

• product;

• source;

• status;

• started time;

• ended time.

If there are no ended access records, the page can show an empty state. That only means the page does not have recent no-longer-active records to show there. It is not a special confirmation of a fresh purchase.

If a record appears in Access history, do not panic-read it. History is the drawer where ended records go. The page names expired, refunded, exchanged, and revoked access as examples of records that can appear there. Those words describe why a record may no longer be current; they are not, by themselves, a support instruction.

That means a history row may be completely expected. It may be old access that expired. It may be access that changed through a refund or exchange. It may be a revoke tied to a subscription or access change. Treat the row as context, then compare it with current products, Billing, and Access if the timing does not make sense.

Access history is not a complete investigation tool. It is a recent no-longer-active access view. If you need to understand a billing event, go to Billing. If you need to understand TradingView delivery, go to Access. If the dates or statuses do not line up with what you expected, that is when the comparison becomes useful.

Products versus Access versus Account

This is the part worth getting clear, because it is where a lot of bad detective work starts.

If Products shows the product but TradingView does not, do not jump straight to "the purchase failed." Work the chain:

1. Confirm the product or package appears on Products.

2. Open Account and confirm Active TradingView username.

3. If the username is missing or wrong, use the Username field and Save username. While saving, the button may show Saving....

4. Open Access and read the matching delivery task.

5. Look for task states such as Approved, Queued, In progress, Completed, or Failed.

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

The purchase, the account inventory record, the active TradingView username, and the delivery task should eventually tell one coherent story. They may not all update in the same breath. The dashboard does not give you a guaranteed sync timer, so the useful move is comparison, not guessing. If Access says a task is Completed but you still do not see the tool in TradingView, make sure you are checking the same TradingView account and the relevant TradingView product area before handing the mismatch to support.

If something you bought is missing

Use this sequence when you expected a product or package and Products does not show it where you expected.

1. Confirm the signed-in Axiom account.

Make sure you are using the same account used at checkout. If the account is wrong, every dashboard page can look convincingly empty.

1. Refresh Products after a little time if checkout just happened.

A fresh checkout can leave Products, Billing, and Access catching up in different places. Do not treat the first empty view as final, and do not wait for a precise dashboard timer. The next useful move is to compare the visible states.

1. Check Billing.

Look for subscription or payment context. Billing is not the same as account access, but it can show whether synced payment or subscription records are visible for the signed-in account.

1. Check Access.

If the product needs TradingView access, look for open, completed, or failed delivery work. The Access queue card on Products is a hint that this page may have the next clue.

1. Check Account.

Confirm the active TradingView username. A missing or wrong username can make delivery look broken even when account inventory exists.

1. Contact support if the pages still do not line up.

Use Contact when Products stays empty for the checkout account, Billing and Access do not explain the state, or the dashboard shows conflicting facts you cannot reconcile. At that point, the visible mismatch is the useful report.

Do not keep buying the same thing again as a troubleshooting step. If the purchase exists but the dashboard state is confusing, support needs the visible facts, not a duplicate order.

If this looks stuck

Products says No active products after checkout

First, confirm the account. Then check Billing for payment or subscription context and Access for delivery work.

If checkout just happened, the account inventory may not be visible yet. The page does not promise instant appearance or a specific wait time. If the state stays empty after the account, Billing, and Access checks, contact support with the purchase details and what each page shows.

Products shows the product, but TradingView does not

This is exactly where Products and Access need to be separated.

Products showing the item means the account inventory side sees access. Now check Account for the active TradingView username and Access for the delivery task. If Access shows open work, watch that state. If it shows Failed, read the failure message and use Retry only if the button appears.

Products shows current access, but Access has no matching delivery row

First, make sure the product actually needs TradingView delivery. Products can include account inventory that does not always have a direct TradingView link.

If the product should be delivered to TradingView, confirm the active username on Account. Then check Access again for matching product, action, status, and requested time. If Products shows current access, the username is correct, and Access still has no matching delivery work, contact support with that exact comparison.

The item says Pending access

Pending access means the item is attached to the account, but the access state is still not fully settled. It is not the same as an empty account.

Go to Access and read the delivery state. If the product needs TradingView access, also check the active username on Account.

The item says Ending

Ending means the item is still current while its ending timing is still in effect. Do not read it as already gone unless the page has moved it out of current products or the relevant timing says it has ended.

If the timing surprises you, check Billing or the subscription detail where available. If TradingView access is the question, check Access.

A product is in Access history

History means the access record is no longer current. It does not automatically mean something broke today.

Look at the status, started time, and ended time. The page supports expired, refunded, exchanged, and revoked access as examples of history. If the history row conflicts with a current subscription, payment, or exchange state you expected, compare Billing and contact support if the facts still do not line up.

Open TradingView is missing

Open TradingView only appears when the product row has a TradingView product link available. Not every product row is guaranteed to show it.

If the card says the account has current access, use Access to inspect delivery and Account to confirm the username. Missing Open TradingView is not proof by itself that the account lacks the product.

A refund action failed or the card says to contact support

If a Request refund action fails, or if the card points to Contact support, stop pressing around the page looking for a hidden refund path.

Use Contact with the product name, purchase timing, account email, visible refund message, and any transaction or subscription context you can see. Refund submission and refund review are not instant refund completion, and Products is not the place to infer a broader refund promise from a missing button.

The product is a package and the rows look different from the purchase name

A package can be the purchased item while the rows underneath are the included products. Read the Package label, then read the included product rows one by one.

If one row has Open TradingView and another does not, that does not automatically mean the package is half-broken. It may mean only one row has a direct TradingView link available. Use Access to inspect delivery state for the products that need it.

Refund and support boundaries on Products

Products can show refund-related information because the card is close to the purchase/access record. Keep that information in its lane.

A card may show:

• Request refund when the page can offer self-serve submission for the current item state;

• Contact support when review is needed instead of automatic submission;

• a refund deadline;

• a latest refund status;

• a blocking reason;

• Not applicable or no refund action.

Use what the page shows. Do not infer a broader policy from a missing button or a visible button.

If you submit a refund request from Products, Paddle is the payment processor that confirms the final refund state. The page can tell you the request was submitted or that the action failed. It does not promise instant approval, instant confirmation, or immediate money movement.

For subscription, cancellation, payment, exchange, or detailed refund questions, use Billing and the visible refund or support path. Products is not the full policy page, and an Exchanges link on a product card is a handoff, not proof that every exchange request will be eligible.

When to contact support

Use Contact when the website stops giving you a safe self-serve move.

That usually means:

• Products remains empty for the account that completed checkout after you have checked Billing and Access;

• Products shows current access, but Access has no matching delivery work for a TradingView product;

• Access shows a failed delivery task without Retry;

• the active TradingView username is correct, but the delivery state still does not explain why TradingView is missing the tool;

• refund submission fails;

• a product card points you to support for refund review;

• account, subscription, access, exchange, or refund states conflict in a way you cannot reconcile from the dashboard.

The contact form asks for Name, Email, and Message. It can also accept optional context and a screenshot. If you attach a screenshot, use PNG, JPG, or WebP and keep it under 5 MB. The form uses a verification step before it sends, so make sure the message actually goes through before you treat support as notified.

Support replies by email, typically within 1-2 business days. That is a response expectation, not an instant access or refund guarantee.

What to send support

Send the plain facts. They are more useful than a polished diagnosis.

Include:

• the email address on your Axiom account;

• the product or package name;

• the approximate purchase time or subscription involved, especially if Billing shows a matching record;

• what Products shows, including the card status;

• what Access shows, including task status or failure message if visible;

• the active TradingView username shown on Account or Access;

• whether Retry, Open TradingView, Request refund, or Contact support is visible;

• any visible refund message or billing context;

• a screenshot if the state is easier to show than explain.

Avoid sending internal guesses. You do not need anything the dashboard does not show. Account, product, username, Products state, Access state, Billing context, and visible messages are the useful map.

Where you should land

You are done with this check when you can say which page owns the next step.

• If the product or package is missing from the signed-in account, start with Products, Billing, and support if they do not line up.

• If the product is visible but TradingView is not, use Access and Account.

• If the issue is a subscription, transaction, or refund state, use Billing and the visible refund/support path.

• If you have no current products and meant to shop, use Browse products.

• If the dashboard shows conflicting facts and no safe self-serve action, use Contact.

Products is the place to find where your account actually stands. Once you know that, the next page is much easier to choose.

Related pages

• Products

• Access

• Account

• Billing

• Browse products

• Contact

• Trial access and conversion