# Raw Card APIs and PCI Compliance: A SaaS Reality Check > Raw card APIs give you full control over the payment form but expand PCI scope dramatically. When the trade off makes sense and when it absolutely does not. - **Author**: Ayush Agarwal - **Published**: 2026-05-16 - **Category**: Compliance, Checkout - **URL**: https://dodopayments.com/blogs/raw-card-api-pci-compliance --- Most SaaS and AI products never need to think about raw card APIs. The hosted or inline checkout from a payment provider handles cards, wallets, local methods, fraud screening, and PCI compliance in a single integration. The provider's frame collects the card data, the provider settles the payment, and the merchant never sees a card number. Then there are products that genuinely need more control. Payment forms with custom flows, optimisations the provider's UI cannot support, integrations with legacy systems, or one off payment processors that only expose a raw card API. For these products the trade off becomes real. You gain control. You also pull yourself into a much larger PCI compliance footprint, and you take on real engineering and audit cost. This article walks through what raw card APIs are, what PCI compliance actually means in practice, when the trade off is worth it, and how Dodo Payments thinks about this surface. ## What raw card APIs are A raw card API accepts the card number, expiry, security code, and cardholder name directly in the request body. Your application code or your front end submits these fields to the provider. The provider authorises the payment, returns a result, and your application moves on. The contrast is with a hosted or embedded form, where the card data goes from the buyer's browser directly into a frame served by the provider. Your application never sees the card number. You only see a token or identifier that represents the saved payment method or the completed payment. Raw card APIs exist because some integrations need the data path to flow through the merchant. Some examples include legacy enterprise integrations where the card has already been collected through a separate channel, custom mobile applications where the merchant wants full control over the input experience, third party systems that submit cards through their own pipelines, and certain compliance programs where the merchant has elected to handle card data and accept the corresponding scope. The capability is genuinely useful for these cases. The cost of using it is what we are going to walk through next. ## What PCI compliance means in practice PCI DSS, the Payment Card Industry Data Security Standard, is the security standard that governs how card data is handled. It applies to any organisation that stores, processes, or transmits cardholder data. The standard is not a single rulebook with one version. It is a tiered framework where the obligations scale with how you handle card data and how many transactions you process. The way PCI applies in practice depends on what is called your scope. Scope is the set of systems and processes that touch card data. Smaller scope means fewer systems, fewer audit points, fewer controls to implement, and a much shorter compliance questionnaire. The smallest scope is SAQ A. This applies when your environment never touches card data because all of it is handled by a fully outsourced provider through a hosted page or a directly delivered embedded frame. SAQ A is a short document, the audit cost is minimal, and most SaaS products land here when they use a hosted or inline checkout from a Merchant of Record. The next step up is SAQ A EP. This applies when your environment does not store card data but does serve the page where the card data is collected, even if the data goes directly to the provider. The questionnaire is longer, certain controls around the page delivery are required, and the scope expands. Beyond that are SAQ D and full PCI DSS Level audits. These apply when your environment actually receives card data. The control set is large and detailed. Encryption in transit, encryption at rest if you store anything, access controls, logging, vulnerability management, regular penetration testing, employee training, network segmentation, and a long list of other obligations all apply. For larger transaction volumes a full Report on Compliance with a Qualified Security Assessor is required, which is a real annual project costing tens or hundreds of thousands of dollars depending on the company size. Using a raw card API where your servers receive the card data pulls you out of SAQ A and into the SAQ D or full DSS world. This is the central trade off. ## When using a raw card API actually makes sense Despite the cost, raw card APIs are the right answer for a small set of cases. ### You already have a PCI compliant environment If your company is already running at the SAQ D or full DSS level for other reasons, the marginal cost of adding a raw card API integration is low. You have the controls, the audits, and the tooling. Adding another flow that uses card data is much smaller than building all of that from scratch. ### You operate in a vertical where card data must flow through your systems Some industries and integrations require the merchant to be in the data path. Travel platforms with global distribution systems, certain B2B procurement integrations, and a handful of regulated verticals fall into this category. If your business genuinely lives in one of these worlds, you do not have a choice and the raw card API is the path. ### You need a payment experience that hosted and inline cannot deliver This is the case to be most sceptical of, because the bar is high. Modern hosted and inline checkout flows are extremely flexible. If your team is convinced you need full control over every pixel of the form, push back hard internally. Most of the time the gap can be closed with a well executed inline integration and the PCI cost can be avoided. ### You have specific regulatory requirements for one off payment flows Some regulated environments have one off requirements that need direct API submission. These are rare in SaaS and AI but do exist. If you are in this position, you usually already know. For most SaaS and AI products none of these apply, and the right answer is a hosted or inline checkout that keeps card data out of your servers entirely. ## What raw card integration looks like If you do go down this path, the implementation pattern follows a few clear steps. You create a payment record by calling the payments create API. The response includes a secret key that authorises the next call. You collect the card data in your front end or back end through whatever flow your environment requires. You call the confirm payment endpoint with the card data, the secret key, billing details, and browser information. Browser information matters because three D Secure authentication uses it to risk score the transaction. The platform attempts the charge. The response either confirms the payment, declines it, or returns a status indicating that further customer action is required, typically three D Secure authentication. If three D Secure is required, you redirect the customer to the URL provided in the response. The customer authenticates with their bank, the bank notifies the platform, and the original payment moves to a final state. You handle the final state in your application, recording the payment and provisioning whatever the customer paid for. The pattern is similar for wallet payments. Apple Pay and Google Pay can be processed through the same confirm endpoint, with the wallet payload in place of the raw card fields. This is an important detail because wallet payments can run through the raw card API surface without actually touching a raw card number, which keeps PCI scope smaller while still giving you the API control you wanted. The full reference for the calls and parameters lives in the raw card API guide. This article focuses on the trade off rather than the request shapes. ## Common mistakes when using raw card APIs Teams that go down this path often hit similar issues. Storing the card data anywhere in your systems. The PCI standard distinguishes between transmitting card data, which is allowed under appropriate controls, and storing it, which is heavily restricted. Storing card numbers in your application database is almost never the right call. If you need a saved payment method, use the platform's tokenisation surface and store only the token. Logging request bodies that contain card numbers. This is one of the most common audit failures. Application logs, error trackers, request mirrors, and analytics pipelines all need to be configured to redact card numbers before storage. Doing this after the fact is harder than doing it from day one. Skipping browser information collection. Three D Secure authentication relies on the browser fingerprint sent with the confirm request. Failing to collect and pass this information causes higher decline rates and worse fraud screening, even when the card itself is good. Treating raw card flow the same as hosted flow operationally. Raw card flow requires real PCI controls. Annual audits, quarterly scans, formal change management, and access reviews are all part of the obligation. If your operations team is not set up for this, the audit will not go well. Underestimating ongoing maintenance. Card networks update rules. Three D Secure protocol versions move forward. Compliance requirements change. With a hosted or inline integration the provider absorbs all of this. With a raw card integration your team does. The maintenance cost is real and continuous. ## How Dodo Payments thinks about raw card APIs Dodo Payments supports both modes. The default and recommended path for SaaS and AI products is hosted or inline checkout, which keeps you in SAQ A scope and removes the PCI burden. The Merchant of Record model means the platform is the seller of record, the platform handles tax, and the platform handles compliance. Your engineering team focuses on the product. For the cases where a raw card flow is genuinely needed, Dodo Payments exposes a raw card API for one time payments including card, Apple Pay, and Google Pay. This is not the path most products should take. It is available for the specific cases where it makes sense. The recommendation is straightforward. Start with hosted or inline. Confirm that the user experience and conversion meet your goals. Only consider raw card if there is a specific requirement that hosted and inline cannot meet, and confirm with your security and finance teams that the PCI cost is acceptable before committing. For implementation reference, the [inline checkout guide](https://docs.dodopayments.com/developer-resources/inline-checkout) and the [overlay checkout guide](https://docs.dodopayments.com/developer-resources/overlay-checkout) cover the recommended paths. The raw card API documentation covers the API shape for the cases that do require it. ## Closing thought Raw card APIs are a tool, and like every powerful tool they are easy to reach for when something simpler would do. The compliance cost is real. The audit cost is real. The maintenance cost is real. For most SaaS and AI products none of those costs are worth paying when a hosted or inline checkout does the job and keeps PCI scope minimal. If you have a specific reason to use a raw card API, do it carefully. Build the controls early. Choose your logging and storage patterns to keep card data out of your systems wherever possible. Treat compliance as an engineering responsibility, not a finance afterthought. And before committing, ask whether the goal you are chasing actually requires this path or whether a well executed inline checkout would get you there with a fraction of the cost. ## FAQ ### Does using a raw card API automatically mean a full PCI DSS audit? It depends on transaction volume and your environment. Smaller volumes can sometimes file SAQ D as a self assessment. Larger volumes typically require a full Report on Compliance with a Qualified Security Assessor, which is a multi month annual engagement. Either way it is a much larger obligation than SAQ A. ### Can I use a raw card API for subscriptions? The raw card API surface is typically scoped to one time payments. For subscriptions, the standard pattern is to use a checkout session with a hosted or inline form that saves the payment method, then run recurring billing against the saved method. This keeps PCI scope small and gives you the full subscription primitives. ### Do Apple Pay and Google Pay through a raw card API count as raw card data for PCI? Wallet payloads are usually treated differently from raw card numbers because the actual card data is not in the request. Most platforms treat wallet payments through the same API surface as keeping you in a smaller PCI scope. Confirm the specifics with your platform and your auditor. ### What is the most common reason teams regret choosing raw card APIs? The audit cost in years two and three. The first year often hides the true cost because the team is still figuring out the controls. By year two and three the recurring audit, scan, training, and remediation work is fully visible, and many teams realise the savings from going hosted or inline would have been substantial. ### Can I switch from raw card to hosted later? Yes. Many teams that started with raw card for early flexibility migrate to hosted or inline later when conversion data and operational cost push them in that direction. The migration is not trivial but it is bounded. Plan it as a project rather than as a quick switch. --- - [More Compliance articles](https://dodopayments.com/blogs/category/compliance) - [All articles](https://dodopayments.com/blogs)