> ## Documentation Index > Fetch the complete documentation index at: https://mso.getlemma.com/llms.txt > Use this file to discover all available pages before exploring further. # Set up card payments > Choosing a processor, card-present versus card-not-present economics, surcharging legality, PCI scope, and saving cards on file compliantly. Card payments are how most patient money arrives. Setting them up well means getting the **settlement destination** right (the PC's account), the **descriptor** right (the practice brand), and the **pricing** right (interchange-plus at any real volume). ## Prerequisites * The PC's operating account open * Your practice brand decided, for the descriptor * Your expected card volume and mix ## Choose a processor | Option | Fits | Watch | | ------------------------------ | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | **Standalone processor** | Groups wanting rate control and portability | Requires integration work | | **EHR-embedded payments** | Small single-entity practices | Blended pricing, lock-in, weak multi-entity support | | **Bank-integrated processing** | Multi-entity groups wanting settlement to follow the entity structure | Availability varies | | **Platform-bundled** | Speed to launch | See [Bundled payroll and processing](/concepts/banking/bundled-payroll-and-processing) | **Test the multi-entity case before signing.** Can each location settle to **its own PC's** account? A processor that settles everything to one configured account will settle your Colorado PC's patient payments into whichever account was set up first, which is a commingling problem, not a configuration preference. ## Pricing: interchange-plus vs blended | | Blended / flat rate | Interchange-plus | | ----------------------- | ---------------------------------- | ---------------------------------------------- | | **Looks like** | "3.5% + 30¢" | "Interchange + 0.30% + 10¢" | | **Transparency** | None, you can't see the components | Full, interchange is published by the networks | | **Cost at low volume** | Simple, often fine | Marginally better | | **Cost at real volume** | Usually worse | Usually better | | **Benchmarkable** | No | Yes | At meaningful volume, ask for **interchange-plus**. The published interchange rates are the same for every merchant; what you're negotiating is the markup, and you can only negotiate what you can see. ## Card-present vs card-not-present | | Card present | Card not present | | ------------------- | -------------------------------- | ------------------------- | | Where | In office, dipped or tapped | Phone, online, saved card | | Rate | Lower | Higher | | Fraud liability | Generally the issuer's, with EMV | **Generally yours** | | Chargeback exposure | Lower | Higher | Encourage in-office payment at check-out where you can. It costs less and disputes less. ## Steps **This is the single highest-value configuration on this page.** Patients recognize "Meridian Dermatology," not "Meridian Health Partners LLC" or "Priya Shah MD PC." Descriptor mismatch is the leading cause of healthcare chargebacks, and the MSO-PC structure makes it worse by design because the legal entity name and the brand differ. Set the descriptor to the brand, include a phone number if your processor supports it, and check what actually appears on a test transaction rather than what the configuration screen says. Patient payments are the practice's revenue. Per entity, per location. See [Structure accounts across your entities](/guides/banking/structure-accounts-across-entities). Passing the processing fee to patients is permitted in some states and restricted in others, and card network rules impose their own requirements including advance disclosure, signage, receipt disclosure, and caps. **Verify both state law and network rules before implementing**, and note that debit card surcharging is generally treated differently from credit. Also weigh the patient-relations cost: a surcharge on a medical bill lands differently than one on a retail purchase. PCI DSS scope depends on how card data flows. To keep it minimal: * Use **point-to-point encrypted terminals** so card data never touches your systems * Use **hosted payment pages** or iframes for online payments, so card data goes to the processor directly * **Tokenize** cards on file — store the token, never the number * **Never** write card numbers on paper forms or store them in the EHR Complete the appropriate self-assessment questionnaire annually. Card data written on an intake form and filed in a chart is both a PCI problem and, in that context, arguably a privacy one. Train the front desk explicitly: never write down a card number. Requires: * **Written authorization** from the patient, specifying what may be charged and when * **Tokenization** — store the processor's token, never the card number * **Notification before charging**, per your policy — this dramatically reduces disputes * A clear way for the patient to revoke Card on file plus autopay is what makes payment plans complete. It is also, done badly, a chargeback generator. The difference is the written authorization and the pre-charge notification. Email or text, automatically. A patient with a receipt disputes far less than one without. Card deposits arrive **net of fees**, in batches that don't align to individual payments. Record **gross revenue and fee expense separately**. Netting them understates both revenue and expense, and it makes your effective processing rate invisible. See [Reconcile payments daily](/guides/payments/reconcile-daily-payments). ## Payer virtual credit cards If a payer sends single-use card numbers instead of EFT, you are paying 2–3% on money that should arrive free. Complete their EFT enrollment and ask in writing to opt out of the card program. See [Paper checks and virtual credit cards](/concepts/payments/paper-checks-and-vcc). ## Verify it worked * [ ] Descriptor tested on a real transaction and shows the practice brand * [ ] Settlement points at the correct **PC's** account, per entity * [ ] Interchange-plus pricing at meaningful volume * [ ] Surcharging decision verified against state law and network rules * [ ] PCI scope minimized; SAQ completed * [ ] Card-on-file authorization form in use * [ ] Cards tokenized, never stored * [ ] Receipts sending automatically * [ ] Gross revenue and fees recorded separately * [ ] Dispute rate monitored against processor thresholds ## Common failure modes | Failure | Consequence | | ------------------------------------------ | ------------------------------------------------- | | Descriptor shows the legal entity name | Chargebacks | | All entities settling to one account | Commingling | | Blended pricing at high volume | Overpaying, invisibly | | Surcharging without checking state law | Regulatory exposure | | Card numbers written on paper | PCI and privacy exposure | | Card on file without written authorization | Chargebacks you will lose | | Netting fees against revenue | Understated revenue and invisible processing cost | | Not monitoring dispute ratio | Reserves or account closure | ## Related topics - [Prevent chargebacks](/guides/payments/prevent-chargebacks.md) - [Reconcile payments daily](/guides/payments/reconcile-daily-payments.md) - [Run patient statements and balances](/guides/billing/manage-patient-statements.md) - [Chargebacks: when patients dispute card payments](/concepts/payments/chargebacks.md) - [Payment rails 101 (ACH, checks, wires, RTP, cards)](/concepts/banking/payment-rails-101.md) - [When platforms bundle payroll and card processing](/concepts/banking/bundled-payroll-and-processing.md) - [Card dispute reason codes](/reference/banking/chargeback-reason-codes.md)