A payment component library is the one piece of your checkout that touches revenue, PCI scope and your processor contract at the same time. Pick it on demo polish and you find the real costs later, when finance wants a second processor or an auditor asks who protects the payment page from injected scripts.
The six questions below work for any payment component library, and I use PaymentKit.js as the worked example. The field notes come from a guest contributor whose product team shipped PaymentKit in production, and I mark them as their results, not mine.
Quick answer: A payment component library is a set of prebuilt checkout fields and buttons that collect card or wallet details inside provider-hosted iframes, so raw card numbers never reach your servers. Choose one by checking six things: payment method coverage, PCI scope, UI control, processor independence, testing tools and back-end integration.
In This Article (10 sections)
Hosted Checkout, Embedded Components or a Raw API?
Before the six questions, settle which integration model you are buying. The model decides how much UI you own and which PCI questionnaire your team starts from.
| Integration model | When to use it | PCI scope starting point | Key trade-off |
|---|---|---|---|
| Hosted checkout (redirect) | Speed matters more than brand control | SAQ A candidate, script criterion does not apply | Customer leaves your page to pay |
| Embedded components (iframe) | You want checkout inside your own UI | SAQ A candidate, plus the script-attack criterion | You must protect the host page or get written provider confirmation |
| Raw API with your own card fields | You need full control and accept the audit work | Outside SAQ A | Card data touches your systems |
Source: PCI SSC FAQ 1588 on SAQ A eligibility, February 2025. Your acquiring bank confirms which SAQ applies to your environment.
For most SaaS checkouts I would start with embedded components, and the rest of this guide assumes that model.
1. Does It Support the Payment Methods Your Customers Use?
Payment method coverage decides how many buyers can finish checkout at all. If a meaningful share of your buyers pay with PayPal or Apple Pay and your checkout shows only card fields, your acquisition spend is fighting a gap you could close in the front end.
PaymentKit.js (https://www.paymentkit.com/) supports four payment methods: cards with 3D Secure handling, PayPal, Google Pay and Apple Pay.
A separate buy now, pay later guide adds Klarna, Afterpay and Affirm, and states that BNPL payments run through your Stripe processor.
That Stripe dependency is the detail I would flag in a buying memo. If you plan to route most traffic through Adyen or Airwallex, BNPL still needs a Stripe account behind it.
PaymentKit’s documentation does not mention local methods such as iDEAL in the Netherlands or BLIK in Poland. Ask the vendor for a written timeline before you promise a regional launch date.
2. How Much Card Data Touches Your Infrastructure?
Every system that sees a raw card number widens your PCI assessment. The goal is simple: your servers receive a token and nothing else.
PaymentKit.js renders payment inputs inside isolated iframes, and the same getting-started guide says this keeps sensitive card data off your servers. In its VGS mode, card fields are collected in VGS Collect secure iframes.
An iframe does not settle PCI scope on its own. Under PCI SSC’s SAQ A guidance, a merchant that embeds a provider’s iframe must also confirm the page is not susceptible to script attacks.
Two routes meet that condition: the controls in PCI DSS requirements 6.4.3 and 11.6.1, or written confirmation from the provider.
PaymentKit’s documentation does not publish an Attestation of Compliance (AOC) or name an SAQ level. Before you sign, ask for three things: the AOC, the SAQ type they expect you to file, and written script-protection confirmation for the embedded form.
3. Can You Build a Checkout That Matches Your Brand?
A full-page redirect is fast to ship and awkward to brand. Growth teams want to A/B test field order and copy, and support staff taking phone orders often want a stripped-down single-column form.
You need those variations without forking the library, and vendors handle it in two ways. Stripe Elements exposes a theming layer, an Appearance API built on CSS-style variables and rules.
Chargebee’s Payment Components take the other route: layout, styling and the surrounding page stay with you, while Chargebee handles card data, gateway routing and 3D Secure.
PaymentKit offers both ends: hosted checkout sessions for the redirect path and PaymentKit.js for embedded fields. Its getting-started guide does not document a theming API, so ask for a styling demo before you commit.
The contributor’s team integrated the embedded fields into a React 18 app. They report the work took half a day and hot reloading needed no special configuration.
4. Can You Switch Processors Without Rewriting the UI?
Processor lock-in shows up as a finance problem first. Rates rise, regional coverage runs out, or you need a second processor for failover, and a library built for one processor turns each of those into a front-end rewrite.
Processor-owned libraries carry that risk by design. Stripe Elements is included in Stripe’s integrated pricing, so leaving Stripe means rebuilding the checkout.
PaymentKit sits in the orchestration layer instead. Its payment orchestration page names Stripe, Adyen, Airwallex, Authorize.net, PayPal and Braintree, and routes by payment method, card brand, currency and transaction value.
The same page says a soft decline from one processor cascades to the next, which is the failover case a single-processor library cannot cover.
Routing rules resolve in a fixed order. A route passed on the checkout session wins, then the account’s default route, then your default processor, and PaymentKit tries each processor in a route until one succeeds.
The same guide says routes can only be defined through the API. A finance lead cannot reroute traffic from the dashboard without an engineer, so plan that handoff before you negotiate rates.
The contributor’s team moved 20% of its European traffic to Adyen this way. They report it took one environment variable and no front-end redeploy.
That is the separation finance needs when it negotiates rates. It also answers the renewal question: if the processor raises prices, can you move volume in a sprint instead of a quarter?
5. Are the Testing and Observability Tools Strong Enough?
Without a realistic sandbox, edge cases reach production. Midnight renewals, currency rounding and failed 3D Secure challenges are the failures customers remember.
PaymentKit’s testing tools cover three areas:
- Sandbox accounts. They run on the production app with test credentials and process test payments only.
- Simulations. These virtual test clocks fast-forward time through trials, dunning retries, renewals and scheduled plan changes. They run in isolation from production data.
- Webhook recovery. Failed deliveries retry five times on an escalating schedule, from one minute to 24 hours, and you can manually retry a failed delivery from the dashboard.
The contributor’s QA team simulated a prorated mid-cycle upgrade with a discount code. They report that setting up the scenario and replaying its webhooks took five minutes.
What I would still ask for is a published list of test card numbers for decline and SCA failure paths. The documentation index does not list one.
6. Can Developers Integrate Beyond the Front End?
After payment, the rest of the workflow runs in your back end: turn on paid features, update billing records and often push the customer into your CRM. That makes the back-end surface as important as the fields.
PaymentKit’s back-end surface looks like this:
- A REST API documented in the PaymentKit API reference, with the OpenAPI spec published as JSON and YAML.
- A Python server SDK, installed with
pip install payment-kit. The documentation lists no official Node.js, Go or Java SDK, so teams on those stacks generate a client from the OpenAPI spec. - Webhooks in
entity.actionformat, such aspayment.succeeded,invoice.paidandcustomer.subscription.created. - Pricing models for flat, usage-based, tiered and package pricing.
For safe retries, PaymentKit sends a unique X-Webhook-Event-Id header, and the same webhooks guide tells you to deduplicate on the event ID. Every webhook is signed with HMAC-SHA256, so verify the signature before you act on it.
The contributor’s ops team wired these webhooks into RabbitMQ. They report about 50,000 test events per hour with no drops, and TypeScript types generated from the spec in minutes.
Buyer Checklist Before You Sign
Copy this into your evaluation doc and get a written answer for each line:
- Which payment methods run through which processor, including BNPL?
- Which local methods are on the roadmap, with dates?
- Can you share a copy of your AOC?
- Which SAQ do you expect a merchant using your embedded form to file?
- Will you confirm in writing that your iframe solution protects the host page from script attacks?
- How are the fields themed, and is a styling demo available?
- How does traffic move between processors, and does the move touch the front end?
- Which test cards cover declines and failed 3D Secure challenges?
- Which server SDKs are official, and what license do they use?
- How are webhooks deduplicated and verified?
Who Owns the Decision and How to Measure It
The six questions span three teams, so give each one an owner before the vendor call. Engineering owns card data scope, testing and back-end integration, design owns checkout control, and finance owns payment method coverage and processor independence.
Adoption risk shows up after launch, so agree on what a working checkout looks like 30 and 90 days in. These are the measurements I would put in that review:
| Measurement | What it tells you | Failure mode it catches |
|---|---|---|
| Checkout completion rate by payment method | Whether the methods you added are used | A method that is live but broken on mobile |
| Authorization rate by processor | Whether routing sends each payment where it is most likely to be approved | A default route that quietly costs approvals |
| Payments recovered by a fallback processor | Whether cascading after a soft decline does real work | Failover that is configured but never fires |
| Webhook deliveries marked permanently failed | Whether payment events reach billing and your CRM | Paid customers without access, or access without payment |
| Time to move a slice of traffic to another processor | Whether processor independence exists outside the sales deck | A switch that still needs a front-end release |
| PCI evidence on file | Whether the AOC, SAQ and script-protection confirmation are documented | An audit request nobody can answer |
If authorization rate or webhook failures move the wrong way in the first 30 days, fix routing and event handling before you add another payment method.
Verdict: Who Should Shortlist PaymentKit
A payment component library is where engineering, design and finance meet, so evaluate it with all three in the room. The contributor’s team chose PaymentKit because it gave them a multi-method, processor-agnostic checkout without custom PCI logic.
My recommendation is narrower. Shortlist PaymentKit if your buyer profile is a SaaS team that needs embedded fields, subscription billing and more than one processor behind a single checkout, because processor independence is where it differs from a processor-owned library like Stripe Elements.
When PaymentKit Is the Wrong Fit
Treat any one of these as a disqualifier:
- You need local methods like iDEAL or BLIK at launch. PaymentKit’s documentation does not list them.
- You need on-premises deployment for regulatory reasons, since PaymentKit runs as a hosted platform.
- Your back end runs on Node.js, Go or Java and you want an official SDK instead of a generated client.
The implementation risk I would close first is compliance. Get the AOC, SAQ guidance and script-protection confirmation in writing before your first production charge.
