What ships in the core today?
A payment element with tabbed methods: card, bank transfer (ACH), Apple Pay, and Google Pay, plus individual field elements when you want to compose your own layout. Card entry arrives already polished: live brand detection with logo badges, validation as the customer types, and a clean signal for when the form is ready to submit. Light and dark themes ship first-class, and the styling stays inside its lane, so nothing collides with your stylesheet.
These are the parts of checkout your team would otherwise spend a sprint polishing, and the parts customers judge you on in the first five seconds. You get them on day one.
How do the two transports work?
Two modes, one setting. Inline renders fields directly in your page, fastest to develop against. Iframe serves the sensitive fields from QorPay's own origin, so card data never enters your page and your PCI questionnaire stays at its minimum. Everything else behaves identically in both modes, so you build once and choose your compliance posture with a single switch.
Your security team will like the shape of that trade: production checkout runs with card data structurally outside your page, and it cost the developers one line to get there.
Can I add my own payment methods?
Yes, at runtime, and they sit beside the built-ins as equals. Wallet-style methods (crypto, BNPL, local redirect rails) take minutes to add; fully custom field methods are supported too, without forking the SDK. A platform can roll a new method out to a subset of merchants behind its own flag and widen it when the numbers say so.
The point is whose roadmap you are on. When a market needs a local rail, you ship it on your schedule, not in a feature request queue.
What's in the Q3 expansion?
The same SDK grows three namespaces, all sharing one foundation and one theming system, so everything you embed looks and behaves like one product:
- KPIs: embeddable dashboard widgets, MRR, churn, cohort, and payment KPIs that drop into your own admin pages.
- Recurring: eight billing components extracted from the Recurring module: Plan Picker, Embedded Checkout, Customer Portal, Subscription Manager, Payment Method Manager, Invoice Viewer, Usage Dashboard, and Cancel-with-Retention.
- Virtual Terminals: Sale, Refund, Void, Capture, and Authorize widgets for operator dashboards, built with the guardrails operator tooling demands. Stripe doesn't offer a virtual terminal; Adyen's isn't embeddable.
On the same foundation sits the Agentic Resource Center (ARC), QorPay's embeddable AI layer. Its first resident, Ask Qora, is in beta now: a concierge you embed anywhere QorElementals runs. Ask it anything about your account ("why was Tuesday's deposit short?", "which subscriptions fail next week?") and it answers in plain language with your real numbers, pulled live from your account. Not a help-center article. Not a canned reply. Your data, answering your question. And when a chart or a refund form says it better than a sentence, Ask Qora renders the right QorElementals widget inline in the conversation. The models behind it are the easy part; anyone can rent those. The moat is the audited pathway: answers grounded in the ledger we settle, actions only through the same confirmations an operator would click.
If I know Stripe Elements, what changes?
Almost nothing, by design: the factory, the elements, the mount, the confirm all work the way your team already expects, so most migrations are a script-tag swap and a backend endpoint change, not a rewrite. The differences are underneath, where they pay you: tokenization terminates in the QorCommerce vault, charges settle on the processor QorPay owns, and the expansion namespaces go places Stripe Elements doesn't: operator tooling and embeddable analytics, not just checkout.
Priced it out lately? The muscle memory transfers for free; the margin difference between an aggregator and a direct processor does not. Bring your Stripe integration to a call and we will map the migration line by line.