Skilled nursing product in development

Ease currently serves behavioral health organizations and is planning a skilled nursing product. Discuss planned scope and availability.

CFO and security lead

SNF Payment Portals: Map Card Data and Verify Outsourced Payment Boundaries

Map SNF payment-portal card flows and merchant responsibilities, then test redirects, embedded forms, receipts, logs and outsourced-service boundaries.

Quick answer

Choose a payment-portal architecture only after mapping where card data enters, travels and can be stored. A redirect and an embedded processor form have different SAQ A script-related eligibility considerations. Outsourcing does not settle all merchant obligations. Confirm the appropriate validation with the compliance-accepting entity and inspect synthetic transactions for leakage into charts, logs and support tools.

A payment page can send card details directly to a processor while other parts of the resident portal still capture sensitive information. Session-replay tools, support attachments or a misconfigured error logger can change the actual data path. The buyer needs an observed flow, not a diagram that stops at the payment button.

PCI SSC's FAQ 1588 explains a specific SAQ A eligibility criterion for embedded payment pages or forms: confirming that the merchant site is not susceptible to script attacks affecting the payment system. That particular criterion does not apply to the described redirect or fully outsourced arrangements. The FAQ does not waive other eligibility criteria or determine the correct assessment for every merchant. PCI SSC FAQ 1588.

Draw the actual payment boundary

Map the resident or family device, facility portal, processor page, confirmation route, billing system, analytics, support tools and logs. Identify who operates each component and which data it receives. Include failed payments, refunds and staff-assisted collection, not only a successful self-service payment.

Use a table such as this original specimen:

Component Intended information Evidence to inspect
Facility portal Account reference and payment initiation Browser requests, form fields and scripts
Processor Card details needed for processing Contracted service scope and implementation documentation
Confirmation return Approved status and transaction reference Redirect parameters or response payload
Billing integration Amount, reference and posting status Actual imported fields and exception records
Support and analytics Only approved operational information Screenshots, recordings, logs and tickets

Specify the intended information rather than assuming a token or reference is harmless in every implementation. The assessor and relevant service documentation should determine how the actual design affects scope.

Compare redirect and embedded designs

With a redirect, confirm that the user reaches the expected processor destination and that return parameters do not expose unnecessary information. Test a failed or canceled transaction so the facility does not mistake returning to the portal for successful payment.

With an embedded form, inspect the parent page and its scripts as well as the frame. PCI SSC describes ways to address the script criterion, including suitable protections or confirmation from the compliant payment provider that its correctly implemented solution supplies the relevant protection. Obtain implementation-specific evidence; a general marketing statement is not that confirmation.

Keep the compliance-accepting entity involved in determining whether an SAQ is required and which one fits. The FAQ commonly points merchants to their acquirer or payment brands for that decision.

Run a synthetic transaction inspection

In the processor's approved test environment, submit a test payment, fail one, cancel one and trigger a support request. Use only designated test credentials. Inspect browser traffic, server logs, analytics events, emailed receipts and support records with the appropriate technical team.

Suppose a failed test creates an error event containing the full form payload. Even if the successful payment bypasses the facility server, that failure path defeats the intended boundary. Correct the capture behavior and repeat both success and failure cases. Redacting a screen after the payload has already entered another service is not equivalent to preventing collection.

Also test whether an account reference or resident name unnecessarily travels to advertising or analytics services. Payment-data and health-privacy assessments are distinct, and the same page can create issues in both.

Purchase against a responsibility map

Obtain the processor's relevant compliance evidence, covered service description, secure implementation instructions and division of responsibilities. Establish who approves script changes, investigates anomalies and updates the data-flow map when vendors or forms change.

The result should be a confirmed architecture, appropriate validation route and evidence that the actual portal follows the intended boundaries. Ease's skilled nursing offering is planned; any future payment functionality would require processor-specific scope and acceptance testing.

Questions & answers

Does using a payment processor automatically make a SNF portal eligible for SAQ A?

No. Eligibility depends on the complete arrangement and applicable criteria. The merchant should confirm its required validation with the entity accepting compliance evidence, commonly its acquirer or the payment brands.

Does a hosted payment form remove the need to examine SNF portal scripts?

Not automatically. PCI SSC distinguishes embedded forms from redirects for a specific SAQ A script-related eligibility criterion. Confirm the actual architecture, secure implementation and all other applicable requirements.

Primary sources

Use the cited source and its applicable version when making a facility-specific decision. These guides explain operational evaluation methods; they are not individualized clinical, coding, or legal advice.