Shopvia

Where we are built differently

Plain-language comparisons with the evidence for each. We describe common designs, not named companies, except for prices that are published on a public page.

We have not used any competitor's product. Where a point is about how some checkouts are built, it is a class of design, not a claim about one company. The only named comparison is published prices, with its date and address, on the pricing page.

Where we do it better

The buyer's browser never sets the price

Some checkouts work out the total in the browser and send it to the server. Ours asks for a quote with product ids and quantities only. The server prices the cart through Shopify, adds your rules and signs the result.

Evidence: Placing an order re-checks the signature, the session and the quote id before anything is created. An online payment is charged the amount in that signed quote, and a captured payment that does not match is refunded in full.

Your store's settings are not handed to anyone who asks

Some checkouts look a store up by its domain name and return all of its settings to any caller. Ours looks a store up by a public key, answers an unknown key with an error, and sends the page only a short list of fields copied by name.

Evidence: Fraud lists, billing, messaging settings and secrets are not part of what the storefront receives. The short public part is visible to anyone who views the storefront: button style, visibility rules, pixel ids and active offers.

Money moves only after a fresh check

An online order is created only after we ask the payment gateway directly and see the payment captured. We also check the signature and re-check the amount against the quote.

Evidence: Each payment attempt follows a fixed state machine with replay protection. A mismatch on a captured payment is refunded in full.

No Shopify app to create and no app keys to paste

Some tools ask you to create your own Shopify app and paste its credentials. With Shopvia, install and sessions are handled by Shopify.

Evidence: There are no merchant-supplied app credentials anywhere in setup. You do connect your own payment gateway keys; those are checked, encrypted and never shown back.

Pincode lookup from our own list

Some checkouts call a public pincode service from the buyer's browser. Ours fills the city and state from an India Post pincode list we host ourselves.

Evidence: The lookup is a server route over an imported dataset, so no request from the buyer's browser goes to a third party.

The OTP comes after the order, not before

Some checkouts ask the buyer for a code before the order exists. Ours places the order, and then sends a code only if you have switched that on.

Evidence: The code is sent after placement and only when you choose it: for no order, every COD order or only high-risk ones. It is never a gate on placing the order.

Pay online after a COD order

A buyer who chose COD can pay online later from the order page and save the difference between the COD price and the online price, when there is one.

Evidence: The paid attempt is bound to the order, the order is edited in Shopify with the discount and then marked paid, and an audited fallback runs if that edit path is not available.

Buyers can fix an address or cancel, and stock comes back

A buyer can change the delivery address or cancel from the order page within the windows you set.

Evidence: Address edits are read back from Shopify to confirm they landed, and they lock once the order is fulfilled or taken by a courier aggregator. A COD cancel restocks the item, which Shopify does not do on its own for unpaid orders.

Measured RTO instead of a promise

Some tools tell you a checkout means fewer RTOs. We do not make that claim. We show you what happened.

Evidence: The RTO page shows measured outcomes by risk band, pincode prefix and payment method, and an RTO-saved figure that is labelled as an estimate. The score is deterministic and each order's reasons are listed.

No countdown timers and no invented urgency

Some checkouts show a ticking countdown on an offer. We do not.

Evidence: A struck-through price appears only from a real compare-at price, a low-stock line only from real inventory, and a real expiry is never shown as a ticking clock.

Each purchase is reported once

The browser and the server both report a purchase to Meta, Google Analytics 4 and Google Ads with the same event id, so it is counted once.

Evidence: An atomic claim on the order lets the order page fire the browser purchase once, even across reloads and tabs. Each order has a send log with retry. We do not claim this lifts your results.

Three payment gateways behind one interface

You use your own account with Razorpay, Cashfree or PayU. The checkout talks to all of them in the same way.

Evidence: Razorpay is live. Cashfree and PayU are built behind the same interface and are switched on after sandbox checks. A gateway without stored keys fails closed.

Buyer details saved under a consent line

Some designs re-send a buyer's details on a timer to keep a server copy current. We do not. The phone field sits under a consent line, and a reminder is queued only when that consent was recorded.

Evidence: A reply of STOP stops reminders, and checkouts that never became orders are deleted after 30 days. Honest limit: a phone number typed into a checkout in progress is saved, encrypted, with that checkout until it is deleted.

Billing through Shopify, with no wallet

Some tools bill from a prepaid balance that you must keep topped up. Ours is billed by Shopify after you approve the plan, with no wallet, no per-order credit and no percentage of sales.

Evidence: Plans are charged by Shopify on Shopify's own page. For published usage prices and a calculator, see the pricing page.

Where we are not ahead yet

This list is as important as the one above. Today:

Some of these are planned; see Coming next on the features page.