Payment processor research
How the checkout direction moved from Square, to Stripe exploration, to a high-risk gateway strategy.
Payment processor research
This page explains how the payment direction changed during prototype development and why the current recommendation is intentionally flexible.
The short version: the storefront should not depend on one mainstream processor for all revenue. The safest first production path is still pickup hold requests, with online payment added only after the store has a processor or merchant account that has approved the exact product mix.
Why the direction changed
The first payment direction focused on Square because the physical store already uses Square at the counter.
That was a reasonable starting point. It would keep online and in-store operations close together, reduce training overhead, and avoid introducing a second financial vendor too early.
The client then raised a fair concern: relying on one processor for both brick-and-mortar and online revenue can create a single point of failure. If one account, policy review, or processor decision interrupts payment acceptance, the business loses too much at once.
That led to a short Stripe exploration. Stripe has excellent hosted checkout tools and developer experience, so it was worth testing as an alternate online checkout path. The issue is not technical quality. The issue is fit for this product category.
Restricted-business risk
Smoke shop ecommerce needs extra care because the catalog can include age-restricted products, tobacco-related products, e-cigarette products, CBD-adjacent products, or other high-risk categories.
Square and Stripe are both strong platforms, but neither should be treated as guaranteed approval for this storefront's full catalog.
The practical concern is account continuity:
- a processor may approve some products and reject others
- online sales may be treated differently than in-person sales
- policy review may happen after development work is complete
- funds or account access can be interrupted if the product mix does not match the processor's rules
For this reason, the prototype should keep payment selection adaptable instead of hard-wiring the business to one mainstream processor.
Current payment architecture
The current direction is gateway-first.
NMI is attractive because it can act as the payment gateway while the backend merchant account can change. The website can keep the same checkout shape:
- Shopper builds a cart.
- API validates product IDs, variant IDs, quantities, stock limits, and prices.
- Browser displays a hosted or embedded payment component.
- Payment details are tokenized by the gateway.
- API submits the token and validated order details through the selected backend merchant route.
That separates the storefront UX from the merchant-account decision.
In plain terms: build the checkout once, keep the backend merchant path swappable.
High-risk merchant candidates
PayKings looked promising during research because it appears focused on high-risk merchant account placement.
That does not mean it is approved yet. It means it is a vendor to contact, disclose the exact catalog to, and evaluate against the store's fulfillment model. If PayKings can place the business with an appropriate merchant account and that account can run through NMI, the NMI gateway direction becomes especially useful.
Other high-risk merchant providers may be worth comparing before launch. The important point is not one vendor name. The important point is using a checkout architecture that can survive vendor changes.
Processor roles
Different providers may still have roles:
- Square: useful for in-store POS and possibly non-restricted merchandise if separately approved.
- Stripe: useful for normal ecommerce patterns, but not the default for this catalog.
- NMI: useful as the payment gateway and proof-of-concept integration.
- PayKings or another high-risk merchant provider: possible path for underwriting and merchant placement.
- Crypto or Solana-based payment: possible future experiment, not the first production checkout path.
Crypto may be worth brainstorming for niche use cases, but it adds customer education, accounting, refund, volatility, and compliance questions. It should not replace the pickup hold or approved merchant-account path for the first serious production release.
One active payment mode
The app can support multiple payment providers in code, but production should run one clearly defined payment mode at a time.
This avoids accidental fallback behavior and reduces attack surface. The API should know which provider is active for the deployment, validate the cart server-side, and expose only the configuration needed for that active mode.
Good production boundaries:
- do not let the browser choose an arbitrary payment provider
- do not trust browser-submitted prices
- do not store raw card details in the app
- keep provider secrets in the API only
- keep pickup hold requests available even if online payment is paused
Recommended path
The recommended path is:
- Keep pickup hold requests as the first production checkout behavior.
- Keep NMI sandbox payment as the online payment proof of concept.
- Prepare the merchant application with the real product list and fulfillment rules.
- Evaluate PayKings and other high-risk merchant providers.
- Use NMI or a similar gateway only after the backend merchant account is approved.
- Consider Square or Stripe only for isolated, clearly allowed merchandise categories.
- Treat crypto as a later experiment, not the launch dependency.
This gives the client a working storefront without pretending the payment-risk question is solved before the business has written processor approval.