Orders

Orders

A single migration can accumulate several financial transactions without becoming several migration projects. Orders preserves each transaction across the account, Statistics > Linked Orders narrows that history to one migration, and My Migrations shows the active configuration for that project after you expand Migrations in the Dashboard.

Use the view that matches the question

Use Orders when you need the account-wide transaction history. Use Linked Orders when you need every transaction associated with one migration. Use My Migrations when you need to confirm the Service, Entity Points Plan, Add-ons, approved custom scope, status, and expiration that are in effect.

How the order lifecycle works

Order type	Purpose	Effect after successful payment and processing
New	Establishes a migration with one fixed migration path, a Migration Service, an Entity Points Plan, optional Add-ons, and applicable approved custom scope.	Creates the baseline project under My Migrations after successful payment. Standard and Managed purchases are available for immediate dashboard use. A Custom purchase can require approved Customization to be prepared and verified before the project is ready to execute that custom scope. The 12-month active service period begins at the successful payment-confirmation timestamp.
Upgrade	Expands supported capability, capacity, Service level, or approved custom scope on the existing migration.	Updates the same migration only after the Upgrade succeeds. The customer pays the incremental difference instead of repurchasing the complete package. An Upgrade does not extend the service period.
Extend	Renews access to the same migration using its latest active configuration as the billing baseline.	Grants a new 12-month access period measured from the successful extension-payment settlement timestamp. Eligible upgrades can be included in the same extension order.

An order type describes a commercial transaction. It does not change the fixed Source Platform → Target Platform path, and it does not replace the migration actions used to continue or perform migration work.

Choose between Orders, Linked Orders, and My Migrations

Review transactions across the account

Open Orders when you need the global transaction ledger. It lists historical transactions across the account, including different migrations, order types, and transaction outcomes.

Orders field	What it tells you
Order #	Identifies the transaction. Use Details in the Actions column to open that order’s transaction breakdown.
Migration Path	Shows which fixed Source Platform → Target Platform project the transaction belongs to.
Service	Shows the Service recorded for that transaction.
Created	Shows when the order record was created.
Type	Identifies the transaction as New, Upgrade, Extend, or another recorded order type.
Amount	Shows the amount associated with that transaction.
Status	Shows the transaction state, such as Paid, Pending Payment, Pending Approval, or Failed.
Actions	Opens the order details and, when available, payment, invoice, or related-migration actions.

Use the Order # search and Filters controls to narrow a large account history. A Paid order can expose Details, Invoice, and Migration. A Pending Payment order exposes Details and Pay so payment can be resumed without creating another order.

Review every order linked to one migration

In the Dashboard sidebar, expand Migrations, select My Migrations, find the project, then select Statistics. The Linked Orders table provides the project-level transaction trail for that migration, including successful, pending, and failed attempts.

Linked Orders field	What it tells you
Order Number	Identifies the linked transaction. Select the hyperlinked Order # to leave Statistics and open that transaction’s Order Details page in Orders.
Created	Shows when that linked order was created.
Type	Identifies whether the record is New, Upgrade, Extend, or another supported transaction type.
Amount	Shows the purchase amount recorded for that order.
Status	Shows the transaction outcome or status, including Paid, Pending Approval, Failed, and other recorded statuses.

Linked Orders is intentionally broader than the active package. A failed or pending order remains useful audit evidence even though it does not automatically change what the migration can use.

Confirm the live migration state

Expand Migrations, select My Migrations, and use the migration’s Statistics view to verify what is operationally active. Plan & Service shows the active Service, Entity Points Plan, Created time, and Expires time. After a successful upgrade, those active values reflect the upgraded package while the project remains on the same migration path.

This distinction is critical when a transaction fails: the failed order remains visible in Orders and Linked Orders, but the live migration continues from the most recent effective successful state.

What Order Details tells you

Order Details is the financial and configuration snapshot for one specific transaction, not a reconstructed summary of the project’s live state. You can reach it from either project-level or account-level history:

• Expand Migrations, select My Migrations, open the relevant migration’s Statistics, then use Linked Orders to select the hyperlinked Order #. Next-Cart takes you directly to that transaction’s Order Details page in Orders.
• From Orders, locate the transaction and select Details in its row.

Typical details include:

• Order #, status, Created time, and Updated time where available;
• the related Migration Path and order Type;
• the Service and Entity Points Plan recorded for that order;
• counted data, locked weights, and Entity Points where shown;
• Add-ons and approved custom work recorded by the order, including itemized Custom Service work where applicable;
• the Payment Summary, customer billing information, payment method, reference, and payment time where available;
• Export Invoice for an eligible Paid order;
• View Migration to move from the financial record to the related project.

Upgrade Order Details

An Upgrade detail page preserves the exact configuration proposed by that upgrade attempt, whether the order ultimately succeeds or fails. This lets you audit what the transaction was intended to change without confusing it with the active configuration.

The upgrade Payment Summary can include:

Upgrade value	Meaning
New Project Value	The calculated value of the project after the selected upgrade changes.
Previously Paid	The amount already paid toward the project’s effective package before this Upgrade.
Base price / Add-ons / other components	The components that contribute to the newly calculated project value.
Total	The additional amount due for this Upgrade order after the previously paid amount is credited.
Paid	The amount successfully settled for the order when payment is complete.

If a failed upgrade attempt proposed a different Service tier, Entity Points Plan, Add-on, or custom scope, its Order Details view will still display that proposed configuration. The live project in My Migrations remains anchored to the configuration established by the last successful transaction.

Extend Order Details

An Extend detail page records the migration configuration used as the extension basis. Review the complete active Service, Entity Points Plan, Add-ons, and approved custom scope, plus any eligible upgrades added to the extension, before payment.

The recorded extension configuration is important because successful settlement starts a new 12-month access period for that resulting package.

Upgrade orders and delta billing

Use Purchase a Migration Upgrade when you need the step-by-step purchase workflow. Use Orders to review the resulting transaction record, billing calculation, status, and effect on the live migration.

Upgrades use differential billing. The customer pays only the additional value introduced by the newly calculated project configuration.

Amount Due = New Total Calculated Configuration Value - Total Previously Paid Amount

In the upgrade flow and Order Details, verify the calculation through New Project Value, Previously Paid, and Total. Do not pay an Upgrade when those values do not match the change you intended to make.

A failed or unpaid Upgrade does not become part of the active package and does not advance the migration to the proposed configuration.

What an upgrade can change

An active migration can be expanded through the supported upgrade path by:

• adding one or more Add-ons;
• selecting a higher Entity Points Plan;
• moving to a higher Migration Service level, including Standard → Managed, Standard → Custom, or Managed → Custom;
• adding approved tailored or custom work where applicable.

Service escalation represents a real change in delivery scope, not a label change.

Escalation	Operational meaning
Standard → Managed	Moves the project from self-service operation to Next-Cart-managed migration execution under Managed Service.
Standard → Custom or Managed → Custom	Adds an approved non-standard technical scope that cannot be satisfied by the active Standard or Managed package alone. This can include tailored configuration, specialized schema adjustments, unique business rules, unsupported platform handling, or bespoke developer work.

Custom Service uses the operation mode agreed for that project: Self-Execute or Expert Handle. The defining factor is the approved custom technical scope, not a nominal Service reclassification.

The migration path remains fixed. An Upgrade order does not restart or extend the active service period.

No downgrades after purchase

Downgrades are not supported for an existing migration. You cannot:

• move from Managed Service to Standard Service or otherwise reduce the purchased Service level;
• reduce the Entity Points Plan;
• remove a purchased Add-on to lower the active package value;
• use an Upgrade order to remove approved custom scope as a pricing downgrade;
• change the Source Platform or Target Platform through an Upgrade order.

If the project requires a lower capacity, removal of purchased capabilities, or a different migration path, purchase a separate New migration. Use the same approach when the required configuration cannot be reached through the supported upgrade path.

How successful and failed upgrades affect My Migrations

Orders record transaction attempts. My Migrations reflects the migration configuration that is actually in effect.

Assume a project has this transaction history:

1. New Migration: Paid
2. Upgrade 1: Paid
3. Upgrade 2: Paid
4. Upgrade 3: Paid
5. Upgrade 4: Failed

Opening Upgrade 4 in Orders or through Linked Orders shows the proposed Upgrade 4 configuration and its Failed status. The project in My Migrations still reflects the effective package established through Upgrade 3 because Upgrade 4 never became a successful transaction.

Refunds are a separate lifecycle event. A full or partial refund can change which purchased components remain effective even though the related historical transactions remain reviewable.

Service validity and extensions

New migration validity

A newly purchased migration receives 12 months of active access beginning at the exact timestamp when the New order’s payment is successfully confirmed. The corresponding Expires value in My Migrations represents the end of that active period.

An Upgrade changes the project configuration but does not restart or extend that validity period.

Extend Migration validity

An Extend order renews the same migration. Extension pricing uses the migration’s latest active configuration as its baseline, including the effective:

• Migration Service;
• Entity Points Plan;
• purchased Add-ons;
• approved custom work or Custom scope.

Failed or unpaid upgrades are excluded because they never became part of the active configuration.

A successful extension grants an additional 12 months of access measured from the exact timestamp of successful extension payment settlement. The new expiration is therefore based on the extension settlement time, not on the original expiration timestamp.

Add upgrades while extending

Eligible changes can be added in the same extension flow. For example, the customer can renew the migration while selecting a higher Entity Points Plan, adding an Add-on, or applying another supported upward change.

Before paying an Extend order, confirm that:

Check	Pass condition
Migration	The order belongs to the intended migration and fixed migration path.
Active package	Service, Entity Points Plan, Add-ons, and approved custom work match the latest effective migration state.
Extension basis	The retained package used for renewal matches the migration that should continue.
Concurrent upgrades	Any additional Service, Plan, Add-on, or approved custom-work upgrade is intentional.
Order type	Extend appears in Order Details.

After the Extend order becomes Paid, return to My Migrations and verify both the resulting package and the new Expires timestamp.

Payment completed but the order is not Paid

Do not use a historical or provider-side transitional status as settlement proof. In the order lifecycle documented here, a completed purchase must reach Paid before it is treated as settled.

If the payment provider or bank indicates that payment was sent but the order is still Pending Payment, Pending Approval, Failed, or otherwise unresolved:

1. do not pay the same order again;
2. open the order Details and confirm the Order #, amount, payment method, and recorded status;
3. preserve the provider or bank payment reference;
4. follow Payment Methods and Verification for the applicable verification path;
5. submit the Order # and payment reference through Support Tickets when the provider shows a completed payment but the order does not reach Paid.

Refund eligibility and money-back questions

Documentation can explain the order and migration state produced by an approved refund, but it does not create a blanket money-back guarantee. Use the Next-Cart Refund Policy as the authority for refund eligibility, exclusions, evidence requirements, approval, and rejection.

If a service result appears not to match the purchased scope:

1. preserve the Order #, migration path, purchased Service, Entity Points Plan, Add-ons, and relevant migration evidence;
2. record the specific expected result and observed result;
3. use Support Tickets when the issue can still be investigated or corrected technically;
4. use the Refund Policy for any refund request or eligibility decision.

A technical defect, failed migration activity, or unresolved support case is not by itself proof that a refund is approved. After a refund decision is applied, use Orders, Linked Orders, and My Migrations to verify the resulting transaction and migration state.

Order statuses

Status	What it means	Customer action
Draft	A Custom Service quote request has been created and the technical scope, itemized custom work, execution responsibility, timeline, and price are still being aligned.	Respond to clarification requests and review each finalized scope item. The order moves to Pending Payment after the finalized quote and order configuration are approved.
Pending Payment	The order exists and is ready for payment, but payment has not been completed. For Custom Service, this follows approval of the finalized quote.	Open Details, confirm the locked order configuration, then select Pay or Pay Now to resume payment. If the configuration is wrong, do not pay it.
Pending Approval	A manual payment workflow is awaiting customer action, settlement arrival, or Next-Cart verification.	Follow the assigned payment instructions. If the payment has already been sent, do not submit it again. Preserve the payment reference and use Payment Methods and Verification for the verification workflow.
Paid	Payment and required verification are complete.	Confirm that the purchase, upgrade, or extension is reflected correctly in My Migrations. For Custom Service, Paid confirms settlement but does not by itself confirm that approved Customization is engineering-ready.
Failed	The transaction did not complete successfully.	Review Details and the provider result. The failed order remains visible but does not become the active migration state.
Cancelled	The order was not completed within the available payment period or was otherwise cancelled.	Review Details and create or request the appropriate order again if the purchase is still required.
Refunded	The order has been fully refunded.	Review Details and the related migration state before continuing work.
Partially Refunded	Only part of the order value has been refunded.	Review Details, Linked Orders, and the migration’s active Service, Plan, Add-ons, and status.
Disputed	The order or payment is in an unresolved dispute.	Preserve payment and order evidence and use the active Support or dispute process until the status is resolved.

Pending Payment is not Pending Approval

A Pending Payment order is waiting for a standard payment action. Pending Approval is used for a manual payment workflow such as Bank Transfer while the required transfer and settlement verification are not yet complete. If the transfer has already been sent, do not duplicate it.

Refund eligibility is defined by the Refund Policy

These statuses describe the transaction state recorded by Next-Cart. Refund eligibility, exclusions, evidence review, approval, and rejection are governed by the Next-Cart Refund Policy.

Review an account-wide order

1. Sign in to Next-Cart.
2. Open Orders.
3. Find the order by Order #, migration path, Created date, Service, Type, or Status. Use Search or Filters when needed.
4. Select Details to review the configuration and transaction state recorded by that order.
5. For a Paid order, select Invoice when a copy is needed or Migration to open the related project.
6. For a Pending Payment order, select Pay, review the locked order details, choose the available payment method, and complete payment.
7. For a Pending Approval order, follow the assigned manual-payment instructions. If the transfer or payment has already been sent, do not submit it again while verification is pending.
8. For a Failed or other unresolved order, preserve the Order # and inspect the recorded details before retrying or contacting Support.

Download an invoice for a Paid order

Billing information recorded with the order is used for the invoice. For a successfully settled order, you can retrieve the invoice later from the transaction history.

1. Open Orders and locate the Paid order.
2. Select Invoice in the order row, or select Details and use Export Invoice.
3. Confirm that the Order #, customer or company information, billing address, and settled amount match the intended transaction.
4. Save the invoice with the Order # for accounting or support reference.
5. If a formal invoice copy cannot be retrieved through the available invoice action, submit a billing support request with the Order #.

A Draft, Pending Payment, or Pending Approval order is not a successfully settled transaction. Use the invoice action after the order reaches Paid.

Review a project’s Linked Orders

1. In the Dashboard sidebar, expand Migrations, then select My Migrations.
2. Find the migration you need to audit and select Statistics.
3. Scroll to Linked Orders.
4. Compare Order Number, Created, Type, Amount, and Status across the project’s complete linked transaction history.
5. Select the hyperlinked Order # in the relevant row. Next-Cart opens that transaction’s Order Details page in Orders.
6. Return to Statistics when you need to compare that transaction with the active Plan & Service, Entity Points, progress, or migration expiration.

After payment succeeds

A successful direct Checkout payment for Standard or Managed Service provides two useful paths:

• View Order Details opens the financial and configuration snapshot for the transaction;
• Go to Migration opens the related project so you can verify the resulting active state.

Use both views when the transaction changes an existing migration. Order Details proves what was purchased; My Migrations proves what is now active.

For Custom Service, Paid proves that the order is settled. If the order includes approved Customization that still requires engineering preparation, use the readiness notification to confirm when that custom scope is ready for execution. Customer dashboard visibility and order history remain available while that work is prepared.

Verify the active state after a transaction

Transaction	What to verify in Orders or Linked Orders	What to verify in My Migrations
New	Status is Paid and the purchased configuration is correct.	The new migration exists with the expected path, Service, Plan, Add-ons, Active status, and a 12-month expiration measured from successful payment confirmation.
Upgrade	Status is Paid, delta billing is correct, and the Upgrade Details contain the intended configuration.	The existing migration reflects the successful upward change without a new migration path or renewed expiration.
Failed Upgrade	Status is Failed and the failed proposed configuration remains visible in that order.	The migration remains at the last effective successful configuration.
Extend	Status is Paid and the retained package plus any concurrent upgrades are correct.	The same migration reflects the expected resulting package and a new Expires time exactly 12 months after extension settlement.

Failure handling

Issue	What to do
Payment was submitted but status is still Pending Approval	Do not pay again. Follow Payment Methods and Verification and preserve the Order # and payment reference.
A Pending Payment order has the wrong configuration	Do not select Pay. Preserve the Order # and create or request the correct order through the applicable purchase or support flow.
Payment provider shows a charge but the order is Failed or unresolved	Preserve the Order # and provider payment reference. Do not create a duplicate payment until Support reviews the transaction.
Upgrade Total does not equal the expected differential amount	Do not pay. Confirm that the Upgrade was opened from the intended migration and compare New Project Value, Previously Paid, and Total. Submit a ticket if the calculation remains unexpected.
A Paid upgrade is missing from My Migrations	Open the Upgrade order Details, preserve the Order # and payment information, then submit a ticket.
A failed upgrade changed the visible live configuration	Preserve the failed Order # and the My Migrations details, then contact Support before continuing migration work.
An extension is based on the wrong package	Do not pay. Compare the Extend order with the latest effective Service, Plan, Add-ons, and approved custom work in My Migrations.
A Paid extension did not update Expires to 12 months after settlement	Preserve the Extend Order #, paid timestamp, and displayed Expires value, then submit a ticket.
A refund status does not match the remaining migration package	Review the affected order and Linked Orders, preserve the displayed migration details, and contact Support before relying on the disputed component.

Next Steps

• Use Purchase a Migration to configure a New purchase and follow the direct Standard/Managed path or Custom Service quote path.
• Use Purchase a Migration Upgrade to configure an Upgrade for an existing migration before reviewing the resulting transaction here.
• Use Payment Methods and Verification for PayPal, card, cryptocurrency, bank transfer, and Payoneer confirmation workflows.
• Use Migrations to operate the active purchased migration, inspect Statistics, and compare Linked Orders with the live package.
• Use Prepare Custom Service Requirements when an upgrade to Custom Service requires tailored or bespoke technical scope.