Indovia reviews marketplace fit, business readiness, product suitability, export capability, data quality, and operational risk before seller access is enabled.

No. Invitation codes are issued for a reviewed seller path and should remain private. Sharing creates identity, ownership, verification, and access risk.

Confirm the code exactly, use the intended invitation route, and contact Indovia if it remains rejected. Do not create buyer accounts repeatedly to bypass review.

Yes, after invitation and approval. Seller permissions are not created by ordinary buyer registration.

Buyer Account manages shopping and buyer records. Seller Console manages store operations, products, orders, shipping, support, finance, reports, and settings.

Indovia may request identity, business, bank, origin, compliance, or product documents. Submit them only through approved seller or admin channels.

Requirements depend on business type and review context. Keep any legal registration name consistent across verification and payout records.

Public store identity is limited. Legal numbers, bank data, private addresses, identity documents, and internal review notes remain protected.

Yes. Access can change after verification, policy, security, risk, product, support, or operational review.

Public pages may show approved store name, logo, city or origin context, description, catalog, reviews, and valid marketplace metrics.

No direct-contact or off-platform payment information should appear in store copy, products, images, Q&A, chat, support, or buyer-facing surfaces.

Origin and city context can support trust and shipping, but a home, warehouse, bank, or legal address should not be exposed beyond legitimate operational need.

Explain business, Indonesian origin, materials, process, product focus, capacity, and quality approach without direct contact, private payment, or unverifiable claims.

Suspended, inactive, incomplete, duplicated, risky, or non-public stores should not remain indexed as active marketplace destinations.

Public sales context must come from valid completed paid marketplace orders and exclude drafts, tests, pending or failed payment, cancellations, duplicates, and invalid data.

Open Seller Support with store URL, visible number, expected basis, and relevant order references. Do not edit orders or finance records to force a counter.

Products must fit Indovia direction, be legally supportable, accurately described, and operationally ready. Restricted products require extra review or cannot be listed.

A listing can wait for completion, verification, category correction, media quality, product data, compliance, stock, shipping readiness, or marketplace review.

A simple product has one main configuration. A variable product uses selectable attributes with variation-specific price, stock, SKU, or media.

Use variations when buyers must choose meaningful options such as size, material, color, pack, or specification. Do not combine unrelated products.

Choose the most specific valid category and subcategory. Incorrect categorization reduces search quality and can mislead buyers.

Use the closest accurate category only when valid, save a draft, and contact support with product type and proposed category.

Include material, origin, dimensions, weight, variation logic, quantity, process, care, intended use, limitations, and packaging context.

No. Images must not expose private contact, external ordering, off-platform payment, QR codes, another marketplace watermark, or unrelated claims.

Use current sellable quantity and stable internal SKUs. Variation stock must represent each option accurately and stop selling at zero.

They support shipping calculation, packaging planning, buyer evaluation, and operational review. Follow field guidance for product or packaged values.

A product can be draft, pending, sold out, hidden, removed, recategorized, attached to an unavailable seller, or awaiting index refresh.

A valid published item should enter search after normal index and cache refresh. Verify status, visibility, category, seller status, and search source if missing.

Seller product prices are entered and managed in IDR. Seller finance, balances, settlement, and payout remain IDR.

Buyer-facing product, cart, checkout, and order presentation uses USD for the global marketplace journey.

Canonical rule `20260726_fx05_product25_shipping10`: seller IDR converts to USD, then applies a 5% FX buffer and 25% product markup for buyer presentation.

Provider shipping amount converts to USD, then applies a 5% FX buffer and 10% shipping markup for buyer presentation.

No. FX buffer and marketplace markup used for buyer presentation are not added to seller product balance or payout.

No. Historical order snapshots remain historical and must not be recalculated under a later FX or markup rule.

Enter the seller IDR price for each sellable variation that differs. Required variations must not remain without valid price or stock.

No. Private price and payment arrangements bypass authorized checkout, records, support, and protection.

Use the real store, workshop, or warehouse from which orders are handed to the courier. All location fields must be operationally accurate.

Use an active operational number needed for pickup or courier coordination. It must not be promoted to buyers for negotiation or payment.

Configured services can include POS EMS, POS EKSPOR, and DHL. Availability depends on origin, destination, postcode, parcel data, and provider response.

No. Sellers must not alter base provider rate logic. Seller responsibility is accurate origin, product data, packaging readiness, and evidence.

Carrier logic can compare actual and volumetric weight and account for packaging. Enter accurate data and follow Seller Console guidance.

Verify paid status, seller order, product, variation, quantity, condition, packaging, destination, courier, documents, and tracking workflow.

Keep courier receipt, tracking number, pickup or drop-off event, label, parcel condition, and supported shipment record connected to the order.

Do not invent data or move conversation off-platform. Use protected order communication or support so correction remains connected to the order.

A child seller order is the seller-specific unit beneath an aggregated checkout. It is canonical for fulfillment, finance allocation, holds, reversals, refunds, and payout allocation.

Parent order summarizes buyer checkout. It must not create a second seller allocation, restock, reversal, or refund effect for the same seller item.

Focus on paid and actionable seller-order states, processing deadlines, shipment readiness, buyer messages, tracking, complaints, returns, and support requests.

Only marketplace and fulfillment context needed for the transaction. Buyer email remains hidden, and recipient phone use is limited to delivery need.

Answer product facts clearly inside Indovia. Do not request direct contact, external ordering, private documents, or off-platform payment.

Refuse the request, keep communication inside Indovia, and report the message through the supported route when risk or repeated behavior exists.

Create the ticket from Seller Console support or order context so seller order, buyer-safe identity, issue type, timeline, and evidence remain connected.

The case connects order, buyer claim, seller response, evidence, and review. Related seller funds can be held while the case remains active.

No. A hold protects the review process and is not a finding that either side is correct.

Provide seller order, product and variation, packing evidence, quantity, condition, label, courier receipt, tracking, communication, and factual timeline.

Explain missing evidence through the supported case path, but do not harass the buyer or move evidence to private channels.

No. Refunds must remain connected to authorized payment, child seller order, ledger, inventory, and case outcome.

Finance, refund, hold, reversal, and payout allocation use child seller order as the canonical unit. Parent aggregation must not repeat the effect.

Appeal availability depends on the case, new material evidence, policy, and review process. Repeating the same claim does not guarantee reopening.

Pending is not yet eligible; available is eligible under current controls; held is restricted during review; reversed reflects a supported cancellation or refund allocation.

The child seller order is the canonical allocation unit. Parent order remains projection and aggregation.

No. Payment confirmation, seller-order state, fulfillment, delivery, complaint window, holds, and finance controls affect payout eligibility.

A complaint can hold funds. An approved refund or reversal updates the canonical child seller order allocation without duplicating the effect at parent level.

Use accurate holder name, bank, and account data requested by Seller Console. Keep ownership supportable and never publish bank data.

Review can depend on eligible balance, bank verification, holds, unresolved cases, suspicious changes, policy checks, or required approval.

Buyer-facing FX buffer and marketplace markup belong to buyer presentation and marketplace economics, not seller product proceeds.

Open Seller Support with child seller order, visible ledger values, expected seller amount, status, and screenshots. Do not alter orders to repair display.

Use approved Seller Console promotion routes. Discounts must be clear and must not create misleading reference prices or private payment offers.

Reviews reflect buyer experience connected to products and stores. They do not replace verification, policy, product data, or operational evidence.

Reports can use seller scopes and filters. Public counters use valid completed-sale logic. Tests, pending orders, cancellations, and invalid records must not inflate either.

Open the underlying Seller Console record, identify required action, complete it in the correct module, and avoid relying only on a notification label.

Team access depends on approved features and permissions. Give only the access needed and restrict ownership, finance, verification, and security controls.

Remove access promptly, rotate shared credentials, review recent activity, and confirm recovery email, phone, and administrator ownership.

Secure the account, preserve evidence, review products, orders, bank and payout data, team access, messages, and support history, then contact Indovia.

Never send passwords, reset links, API keys, payment credentials, unnecessary identity documents, or unnecessary buyer contact data.