Why the payment step belongs on the web

By Abdalla Kamesh · Published September 19, 2026 · 5 min read

There is a marketing race in this category to claim the most native app, and the claim that keeps getting stretched is checkout. So here is the unglamorous truth, stated by a vendor about its own product: the card form in a StoreToNative app is a web page on your store, and that is a deliberate design decision rather than a limitation we are working around.

Almost every competitor does the same thing. One of them states it plainly on their own WooCommerce page: the final checkout screen is loaded in a WebView. The difference between products is not whether the browser appears — it is where.

What a fully native checkout would actually require

Suppose we built a native card form. To take a payment, that form has to:

Collect card data inside your app, which pulls your app into PCI DSS scope. Not your store’s scope — the app’s.
Integrate natively with every gateway your merchants use. Not one. Stripe, PayPal, Braintree, Adyen, Mollie, Razorpay, regional gateways, bank-specific gateways, cash on delivery, bank transfer.
Reimplement 3-D Secure and every regional strong-customer-authentication flow, each with its own redirect and challenge behavior.
Reimplement your discount rules, tax calculation, shipping logic, fees and plugin-driven checkout fields — accurately, or the app charges a different total than the website.
Stay correct as each of those changes, forever.

Every one of those is a place to be subtly wrong about money. And “subtly wrong about money” is the one category of bug that a store cannot absorb.

What handing off protects

Putting the payment step on your store’s own checkout pages means:

Your gateways keep working, all of them. Any gateway that works on your website works in the app, including the one your bank insisted on that has no mobile SDK. No compatibility list, no waiting for a vendor to add support.

Your PCI scope does not change. Card data never touches the app or our infrastructure. This is a security property, not a paperwork convenience.

Your totals are your store’s totals. One calculation engine — WooCommerce’s — for web and app. No drift between what the app shows and what the order records.

Your settlement and fraud tooling are untouched. Same account, same payout schedule, same chargeback process, same rules you have already tuned.

No platform commission. Because these are physical goods paid for through your own checkout, Apple’s in-app purchase system is not required, so neither Apple nor Google takes a cut. Neither do we.

That last point is worth pausing on: a fully native card form would not remove a commission, because there was never one to remove. The hand-off is not a tax; it is the reason there is no tax.

Where the line should sit

Here is the part that separates a well-designed hand-off from a lazy one. In a shopping app, several things happen between “I want this” and “here is my card”:

Review the cart, change quantities, remove something
Apply a coupon
Enter or pick a shipping address
Choose a shipping method and see the cost
See the final total
Pay

Only step 6 needs the browser. In a StoreToNative app, the cart is native, and an optional native address and shipping step covers steps 3 to 5 — so the shopper has made every decision, seen the real total, and committed, before the browser appears once, for the payment itself.

A weaker implementation hands off at step 1: tap “cart” and you are on a web page for the whole flow. Both are described as “checkout in a WebView.” They are very different experiences, and the difference is measurable in completed orders.

What a good hand-off looks like

Four properties. Check them on any app you evaluate, including ours:

It is fast. The checkout page loads once. If it is slow, that is your store’s checkout being slow, which is worth fixing for your web customers too.

It matches. Your checkout page’s styling should not look like a different company. If your web checkout is unstyled, this is visible in the app.

It carries the cart. Everything the shopper chose — items, variations, coupon, address, shipping method — arrives pre-filled. A hand-off that makes them retype an address is a hand-off that loses orders.

It comes back. After payment, the app returns to a native order-confirmation screen, and the order appears in native order history immediately. A hand-off that dead-ends on a web thank-you page and leaves the customer stranded in a browser is broken.

What this means for App Review

Reviewers see a lot of store apps. A single web page at the payment step, after a native browsing experience and a native cart, is a normal e-commerce pattern rather than a red flag — and it is worth one sentence in your App Review notes explaining that these are physical goods paid for on the merchant’s own gateway.

The rejection risk under Guideline 4.2 comes from apps where the browsing is a web page. That is a different problem, and it is not fixed by the checkout being native.

What to ask a vendor

Three questions, and the answer to the first should be a screen recording:

Show me the flow from cart to payment. Which screens are native and where exactly does the browser appear?
Is the address and shipping step native, or part of the web page?
After payment, where does the customer land? Native confirmation, or a web page?

Anyone claiming a fully native card form should get a fourth question: whose PCI scope is that, and which gateways do you support? The answer is usually more interesting than the claim.

The honest summary

We are semi-native at checkout, on purpose. The browsing is native because that is where the shopping happens and where speed converts. The payment is on your store because that is where the money, the compliance and the correctness live. Anyone selling you a different story about physical-goods checkout is either doing something more complicated than they are admitting, or describing the same architecture with better adjectives.

Related reading

The FAQ answers this one directly, in the same words we use in sales calls.