Sellvia Payments

I opened the Sellvia dashboard after an order appeared and initially tried to reconcile everything as if I were looking at a normal merchant account: a customer paid, an order existed, and the money should now be sitting somewhere waiting for me. That mental model turned out to be the wrong one. The current Sellvia documentation separates the customer-facing payment from the commission and order-processing system that a Partner Storefront owner sees inside the dashboard.

That distinction changes how Sellvia Payments should be understood. It is not simply a case of “the customer pays me, Sellvia holds my money, then I withdraw it.” Under Sellvia’s current Partner Storefront terms, the customer-facing transaction and the partner’s Pending, Incoming, and Available Commission are legally and operationally separate layers. Connect your own payment provider, and the model changes again.

If you need the wider platform assessment rather than this payment-system deep dive, our Sellvia review covers pricing, features, the product model, user ratings, and the overall editorial evaluation. Here, I am keeping the scope deliberately narrower: who takes the payment, what appears in the dashboard afterward, and which parts of the process are easy to mistake for the same transaction.

The First Thing to Understand: Sellvia Now Documents Two Payment Models

The most useful piece of current Sellvia documentation is not a fee table. It is the distinction between two operating models. Once I read those definitions side by side, several dashboard behaviors that had looked inconsistent started making more sense.

This matters because a lot of older explanations of Sellvia Payments use a much simpler model: customer payment goes into a Sellvia balance, the balance clears, then the store owner withdraws it. A separate Sellvia Payments Terms page still uses language close to that older explanation, describing a hosted payment page at checkout.sellvia.com, major card payments via Stripe, and an account balance credited after a successful transaction.

But the current general Sellvia Terms go further and draw a legal line between customer payments and Partner Storefront Commission. For a current account, I would use the general Terms, the live dashboard, and the newest Help Center guidance together rather than assuming one older description explains every account configuration.

What Sellvia Payments Actually Does

Sellvia’s separate Payments Terms describe Sellvia Payments as an ecommerce payment solution with a secure hosted payment page. That page handles the customer-facing checkout flow, while major card transactions are described as being processed via Stripe. This is a more precise description than calling Sellvia itself a generic “payment processor.” Sellvia provides the hosted commerce layer and account workflow; Stripe is named in the Payments Terms as the card-processing provider for major credit cards.

The current general Terms add another layer. For a Partner Storefront, the partner is not treated as the party directly taking the customer’s payment. Instead, Sellvia handles the customer-facing transaction within its ecosystem and separately tracks Commission associated with qualifying partner activity. That Commission then follows its own validation and redemption rules.

This separation is easy to miss because the dashboard naturally presents orders, earnings, processing actions, and payout controls in one place. From a usability standpoint that integration is one of Sellvia’s strengths. From an accounting standpoint, however, the screens should not be read as proof that the same customer dollar is literally being moved from one labeled bucket to another.

The “Four Payments” Problem Is Really Four Different Money Events

I still find the four-event model the easiest way to read the system, with one correction: in a Partner Storefront, these are not four transfers of the same customer money. They are four different financial or accounting events connected to one commercial outcome.

Event #1: the customer-facing payment. This is what the buyer sees. Under the Partner Storefront model, the current Terms say the partner does not directly receive or handle that payment. Under Customer-Managed Payments, the store owner’s own provider handles it.

Event #2: the dashboard Commission entry. For a Partner Storefront, Sellvia currently defines Commission as an internal, Sellvia-funded promotional incentive associated with qualifying partner activity. Pending Commission is associated with unprocessed orders; after processing, the Commission can move into Incoming for validation and later into Available.

Event #3: order processing. The partner still has to complete the operational step that tells Sellvia to process the order. Manual processing can charge a saved card. Order Processing Credits can automate the step when sufficient credits are available. This action is not the customer’s checkout transaction.

Event #4: redemption or payout. Once Commission is Available and the account satisfies the current eligibility requirements, the partner can request redemption through one of the supported methods. The current Terms explicitly describe these payouts as being made from Sellvia’s corporate funds rather than as settlement of customer funds.

Once I stopped drawing one imaginary line from the customer’s card to my bank account, the dashboard became easier to interpret. The more accurate question is not “Where is the customer’s money right now?” but “Which Sellvia event am I looking at: checkout, Commission status, processing, or redemption?”

What the Customer Sees — and What the Partner Does Not

On the customer side, the experience is intentionally simpler. The buyer chooses a product, reaches the order-completion flow, enters payment details, and receives confirmation when the transaction succeeds. Sellvia’s Payments Terms describe a hosted checkout page and support for major credit cards via Stripe.

The current Partner Storefront terms are even more important here. They state that when no independent payment system is connected, the Partner Storefront serves as the promotional and pre-checkout layer, while order completion happens within Sellvia’s customer-facing environment. The partner therefore sees the attributed order and Commission workflow, not a conventional merchant settlement account containing the buyer’s funds.

If the store owner connects an independent provider, this picture changes. The owner’s chosen payment system handles authorization, capture, transaction records, customer refunds, and payouts according to that provider’s rules. In other words, “How did the customer pay?” and “How does the Sellvia account show my earnings?” are only the same question in certain account setups.

Sellvia Payments, Commission, Order Processing, and Payout Are Not Synonyms

This is the distinction I would want in front of me before looking at any fee percentage. The terminology sounds adjacent, but each term answers a different question.

Following One Partner-Storefront Order Without Turning It Into a Cash-Flow Guide

The full Pending-to-bank mechanics are already a separate topic, so the useful version here is shorter: follow the order only far enough to understand where Sellvia Payments stops and the Commission system begins.

1. A customer completes the checkout flow. In the Partner Storefront model, current Sellvia terms do not treat the partner as the direct recipient of that customer payment.

2. The order appears in the Sellvia workflow. The partner can see that qualifying activity has occurred and that an order requires processing. Pending Commission can be associated with the unprocessed order.

3. The order is processed. With sufficient Order Processing Credits, this can happen automatically. Otherwise, the current Help Center describes a manual “Process order” action paid with a saved card or another card entered during processing.

4. Commission moves into validation. Current documentation describes Incoming Commission as lasting up to 72 hours while Sellvia validates the attributed activity and order completion. The Help Center presents the same dashboard timing in a more user-facing balance format.

5. A portion becomes Available. Sellvia’s current Help Center describes 75% moving to Available after the 72-hour period and 25% remaining in Risk Reserve for 125 days. The general Terms use more careful language: typically up to 75% may transition to Available, while the remainder can stay in a Commission Validation Window for up to 125 days and the exact allocation may depend on account factors.

6. Available Commission can become eligible for redemption. That is the point where payout requirements matter. It is still useful to distinguish “Available in the dashboard” from “already transferred to an external bank account.”

Customer Payment ≠ Commission Balance ≠ Bank Transfer

This is the one accounting distinction worth keeping in the article because it prevents nearly every later misunderstanding.

Customer payment is the buyer-facing transaction. In the Partner Storefront model, Sellvia’s current general Terms say the partner does not receive or handle that payment directly.

Commission balance is an internal Sellvia account record associated with qualifying partner activity. Current Terms explicitly say it is not customer money, a deposit account, stored value, or a wallet.

Bank transfer is one possible method of redeeming eligible Available Commission after the applicable account requirements are satisfied. The Terms state that Sellvia funds approved Commission payouts from its corporate funds and uses third-party providers to execute payout transfers.

The interface can make these stages feel like one financial pipeline because the same order connects them operationally. The documentation says they should not be treated as one continuous custody chain. That is a subtle distinction, but it is probably the single most useful thing to understand before trying to reconcile a Sellvia dashboard against a buyer’s order total.

What Sellvia Payments Fees Actually Apply To

The headline fee number needs context because Sellvia publishes different kinds of charges for different actions. The current dashboard Fees guide and the current general Terms list a 20% Referral Fee for completed orders processed through Sellvia checkout. The Help Center describes this fee as covering payment processing, dispute and refund risk, fraud protection, and the transaction infrastructure around the checkout.

Order processing is separate. The current Fees guide lists a processing fee range for the order-processing service, while automated processing through Order Processing Credits can carry its own additional fee. Moving Available Commission into Order Processing Credits is also documented as a separate redemption path with its own charge. These are different events, so adding them together and calling the total “the Sellvia Payments fee” creates more confusion than clarity.

Advertising fees are outside the scope of Sellvia Payments altogether. They belong to the optional promotion system rather than to customer checkout. I would only include them in a total-cost analysis, not in an explanation of how a customer transaction is handled.

Why Sellvia’s Own Payment-Fee Pages Do Not Currently Match

This is one of the most important details I found while checking the article. Sellvia’s current general Terms and its newest dashboard Fees guide list the referral fee at 20%. A separate Sellvia Payments Terms page still states that a 7% commission is deducted from each transaction.

Those numbers are too far apart to smooth over with vague wording. They are different official statements. The most responsible way to use them is to identify which document governs the account model being discussed and then confirm the live figure inside the dashboard before relying on any published percentage.

This is also why screenshots are unusually valuable for this topic. A dated screenshot of the actual Fees screen answers “what applied to this account at this moment” much more reliably than an undated number copied from a review site.

What Changes When You Connect Your Own Stripe or PayPal?

This is where the two-model distinction becomes practical rather than legalistic. Sellvia’s current Fees guide says a store owner can connect another supported payment provider, including Stripe or PayPal. In that case, Sellvia says the selected provider handles checkout, authorization, capture, refunds, and payouts, and the Sellvia referral fee attached to its own checkout does not apply.

The current general Terms call this the Customer-Managed Payments Model. Under that model, the store owner is responsible for the customer-facing transaction and uses the provider’s own records for payment status, disputes, refunds, and payout timing. Sellvia’s role is then centered on the product and order-processing side rather than on the customer’s payment account.

That difference is much more meaningful than a simple “Sellvia Payments vs Stripe” comparison. The choice changes who owns the payment workflow:

For someone evaluating Sellvia, this is a useful choice rather than a hidden technical detail. The built-in route reduces the number of separate systems a beginner has to configure. The independent-provider route gives a more conventional merchant relationship with the selected gateway but also moves more payment responsibility onto the store owner.

Refunds and Disputes: Who Actually Authorizes What?

The separate Sellvia Payments Terms are specific about the refund sequence. A customer submits the refund request to the ecommerce store where the purchase was made. The client authorizes and instructs the refund, and Sellvia Payments then facilitates the reversal. Those terms state a standard processing timeframe of 5–8 business days from authorization, while acknowledging that the final posting time can vary by payment method.

That is more precise than saying “Sellvia authorizes the refund.” In the Payments Terms model, Sellvia Payments processes the refund after receiving client authorization. In the current Partner Storefront model, meanwhile, the general Terms place the customer-facing sale and payment obligations on Sellvia’s side of the transaction. The exact route therefore depends on which account/payment model applies.

Disputes and chargebacks are also one reason the platform separates immediate activity from immediately redeemable Commission. Sellvia’s current documentation repeatedly links validation, delayed allocation, and payout controls to fraud, disputes, refunds, and account risk. That makes the holding structure easier to understand as a risk-management mechanism rather than as an unexplained delay.

One Odd Exception in Order Processing Is Worth Knowing

The standard rule in Sellvia’s Help Center is simple: Order Processing Credits can process orders automatically, while an account without sufficient credits processes them manually with a card. The Balance and Payouts guide also says Commission Balance cannot normally be used directly to process orders; Available Commission can instead be converted into Processing Credits.

There is, however, a documented exception near the unprocessed-order deadline. Sellvia’s current order-processing guide says that before an unprocessed order is canceled after seven days, the system makes one automatic attempt to process it using Available balance. The general Terms describe the same concept more precisely: after approximately six days and eighteen hours, Sellvia may apply Available Commission Balance to processing costs, fees, and charges in an effort to avoid cancellation.

I would treat that as an exception, not as the normal way to pay for processing. The normal workflow remains card payment or Order Processing Credits; the late-stage use of Available Commission exists as a fallback described in current documentation.

Where Identity Verification Fits

Identity verification is separate from both the customer’s card transaction and the order-processing action. It matters when the partner wants to redeem eligible Commission externally.

Sellvia’s Help Center currently says Veriff is used for identity verification before a first bank withdrawal, alongside phone-number verification. The same Help Center page describes a $4.99 one-time verification charge. The current general Terms, however, state $4.50 for each identity-verification attempt, regardless of outcome.

Again, those official pages do not perfectly match. I would not hide that discrepancy or pick one number as timeless. The useful takeaway is stable: verification is an account-holder check linked to payout eligibility, not part of the customer’s checkout authorization. The exact fee displayed in the live account should be checked before initiating verification.

If the Numbers or Statuses Do Not Match What You Expected

The fastest way to troubleshoot Sellvia Payments is to stop looking at the account as one balance and identify which system owns the question.

What I Check Before Relying on a Sellvia Payment Number

After working through the documentation, I use a short checklist instead of trying to remember every percentage:

• Which payment model is active? Partner Storefront or Customer-Managed Payments changes almost every payment-related answer that follows.
• Who actually handled the customer’s checkout? Sellvia’s checkout environment and infrastructure, or an independently connected provider?
• What is the order-processing status? A successful customer-facing transaction does not mean the Sellvia processing step is complete.
• Which Commission state is shown? Pending, Incoming, Available, and the longer validation/Reserve stage mean different things.
• What does the live Fees page say today? Sellvia’s public documents can lag one another, so the account-specific view matters.
• Is the question about checkout, processing, or payout? They have different fees and different records.
• Are payout prerequisites satisfied? Verification, account status, and method-specific minimums can matter even when Commission is Available.
• Do I have a screenshot of the relevant screen? For any fee or balance dispute, a dated dashboard screenshot is stronger evidence than memory.

What Sellvia Payments Gets Right

The built-in approach makes more sense once the system is read on its own terms. A beginner can use one connected environment for storefront activity, attributed orders, processing, Commission status, and redemption rather than assembling several unrelated tools before the first transaction appears.

The dashboard also exposes the stages instead of hiding them behind one vague “earnings” number. That can feel complicated at first, but the labels provide useful operational information: an unprocessed order is different from Commission under validation, which is different again from Commission that has become eligible for redemption.

The strongest part of Sellvia’s current structure is therefore not that every payment concept is simple. It is that the platform gives users a built-in route and, for those who want more control, documents an alternative Customer-Managed Payments route using an independent provider. Knowing which route an account is using makes the rest of the dashboard much easier to read.

Final Take: Sellvia Payments Makes More Sense Once the Layers Are Separated

The biggest mistake I made when first looking at Sellvia Payments was assuming every money-related number belonged to a single customer-to-seller transfer. Current Sellvia documentation paints a more specific picture. In a Partner Storefront, customer checkout, Sellvia-funded Commission, order processing, and Commission redemption are connected operationally but are not described as the same money moving through four wallets. With Customer-Managed Payments, the store owner instead handles the customer transaction through an independent provider and takes on that provider’s payment workflow.

That distinction is more useful than memorizing one fee percentage. It tells you where to look when a transaction seems missing, why a Commission figure is not the same thing as customer settlement, why order processing is its own action, and why an external Stripe or PayPal setup behaves differently from Sellvia’s built-in route.

For the full platform decision — including pricing, features, editorial rating, user feedback, and how the rest of the Sellvia ecosystem fits together — see our complete Sellvia review. This page is intentionally the narrower payment-system companion to that main Sellvia profile.

Frequently Asked Questions