@cloudstreamsoftware/claude-tools 1.0.0 → 1.1.0

package/skills/compliance-patterns/pci-dss/saq-a-requirements.md

@@ -0,0 +1,307 @@
+# PCI-DSS SAQ-A Requirements
+
+## Overview
+
+Self-Assessment Questionnaire A (SAQ-A) is the simplest PCI-DSS compliance path, applicable when **all payment processing is fully outsourced** to a PCI-certified third party (like Zoho Payments or Stripe) and the merchant never handles, processes, or stores cardholder data on their own systems.
+
+This is the ONLY PCI compliance path CloudStream should implement for clients. Any deviation from SAQ-A eligibility means the client needs a Qualified Security Assessor (QSA) -- refer them to a PCI specialist.
+
+> **WARNING**: SAQ-A eligibility is LOST if your application touches raw card data at any point -- even in transit, even in an error log, even in a URL parameter. Hosted payment pages are mandatory.
+
+---
+
+## SAQ-A Eligibility Criteria
+
+### All of the following MUST be true:
+
+| # | Criterion | How We Ensure It |
+|---|---|---|
+| 1 | All payment processing outsourced to PCI-validated provider | Zoho Payments / Stripe hosted pages only |
+| 2 | No electronic storage of cardholder data | No card fields in Creator forms |
+| 3 | No processing of cardholder data on merchant systems | Redirect to hosted page, receive only tokens |
+| 4 | No transmission of cardholder data through merchant network | iFrame/redirect approach, no server-side card handling |
+| 5 | Merchant does not serve payment page (all hosted) | Zoho Checkout / Stripe Checkout pages |
+| 6 | Merchant confirms provider is PCI-DSS compliant | Verify Zoho/Stripe Attestation of Compliance (AoC) |
+
+### Eligibility Disqualifiers
+
+If ANY of these are true, SAQ-A does NOT apply:
+
+- Client's website serves the payment form (even with JavaScript tokenization) --> SAQ-A-EP
+- Card data passes through client's server for any reason --> SAQ-D
+- Client stores any cardholder data (even encrypted) --> SAQ-D
+- Client uses a virtual terminal for manual card entry --> SAQ-C-VT
+- Client has a physical POS terminal --> SAQ-B or SAQ-C
+
+---
+
+## Annual Self-Assessment Process
+
+### Timeline
+
+| Month | Activity |
+|---|---|
+| January | Begin annual SAQ-A review |
+| January | Request updated AoC from payment providers |
+| February | Complete SAQ-A questionnaire |
+| February | Conduct internal vulnerability review |
+| March | Submit SAQ-A attestation |
+| March | File with acquiring bank/payment processor |
+| Quarterly | Review for changes that affect eligibility |
+| Ongoing | Monitor for security incidents |
+
+### SAQ-A Questionnaire Sections
+
+The SAQ-A contains requirements from the following PCI-DSS sections:
+
+1. Requirement 2 - Default passwords changed
+2. Requirement 6 - Secure systems (web application security)
+3. Requirement 8 - Authentication controls
+4. Requirement 9 - Physical access (if applicable)
+5. Requirement 12 - Security policy documentation
+
+---
+
+## 12 PCI-DSS Requirements Mapped to Zoho Implementation
+
+### Full Requirement Mapping (SAQ-A Applicable Items Only)
+
+| PCI Req | Requirement | SAQ-A Applicable? | Zoho Implementation |
+|---|---|---|---|
+| 1 | Install and maintain network security controls | Partial | N/A - Zoho manages infrastructure |
+| 2 | Apply secure configurations | YES | Change default passwords on all Zoho accounts |
+| 3 | Protect stored account data | YES (by exclusion) | We store NO cardholder data - tokens only |
+| 4 | Protect data in transit | YES | Zoho enforces TLS 1.2+ on all connections |
+| 5 | Protect from malicious software | Partial | Zoho manages endpoint security for SaaS |
+| 6 | Develop and maintain secure systems | YES | Secure Deluge coding practices, input validation |
+| 7 | Restrict access by business need | YES | Role-based access in Creator (see SOC 2 access controls) |
+| 8 | Identify users and authenticate access | YES | MFA, unique IDs, password policies in Zoho One |
+| 9 | Restrict physical access | Minimal | No on-premises cardholder data storage |
+| 10 | Log and monitor access | Partial | Deluge execution logging, Creator audit trail |
+| 11 | Test security regularly | YES | Quarterly review of payment integration |
+| 12 | Support information security with policies | YES | Security policy documentation required |
+
+---
+
+## Documentation Requirements
+
+### Required Documents for SAQ-A
+
+| Document | Purpose | Update Frequency |
+|---|---|---|
+| Information Security Policy | Overarching security governance | Annual review |
+| Incident Response Plan | Procedures for security incidents | Annual + after incidents |
+| Payment Provider AoC | Proof of provider PCI compliance | Annual (request from provider) |
+| SAQ-A Questionnaire | Self-assessment responses | Annual |
+| Attestation of Compliance (AoC) | Merchant's compliance declaration | Annual |
+| Network Diagram | Shows payment flow | Annual + on changes |
+| Data Flow Diagram | Shows where card data does/doesn't go | Annual + on changes |
+| Vendor Management List | All third parties in payment flow | Annual review |
+| Change Control Records | Evidence of change management | Ongoing |
+| Access Control Documentation | User access matrix | Quarterly review |
+
+### Payment Data Flow Diagram (Required)
+
+```
+Customer Browser
+    |
+    | HTTPS (TLS 1.2+)
+    |
+    v
+Client's Zoho Creator Portal
+    |
+    | (1) "Pay Now" button clicked
+    | (Redirect URL generated - NO card data)
+    |
+    v
+Zoho Checkout Hosted Page  <--- PCI BOUNDARY
+    |                            (Everything below is
+    | (2) Card entered here      Zoho's PCI responsibility)
+    |     (Customer ↔ Zoho ONLY)
+    v
+Zoho Payment Gateway
+    |
+    | (3) Card processed
+    |
+    v
+Card Network (Visa/MC/Amex)
+    |
+    | (4) Authorized/Declined
+    |
+    v
+Zoho Payments
+    |
+    | (5) Token + status returned to Creator
+    | (NO card data in this response)
+    |
+    v
+Client's Zoho Creator  <--- OUTSIDE PCI BOUNDARY
+    |                        (Only receives tokens)
+    | (6) Token stored for future use
+    | (7) Customer notified of result
+    v
+Payment Complete
+```
+
+> The dotted PCI boundary shows that card data ONLY exists within Zoho's PCI-certified environment. Client systems never touch it.
+
+---
+
+## Quarterly Network Scans
+
+### SAQ-A Scan Requirements
+
+For most SAQ-A merchants (e-commerce only, no direct internet-facing payment systems):
+
+- **External vulnerability scans**: Generally NOT required for pure SAQ-A
+- **Internal scans**: NOT required for SAQ-A
+- **However**: If you have ANY internet-facing systems that could affect payment security, quarterly ASV scans ARE required
+
+### When Scans ARE Required for SAQ-A
+
+| Scenario | Scan Required? | Type |
+|---|---|---|
+| Pure hosted payment redirect | No | N/A |
+| Client website hosts payment iFrame | Yes (SAQ-A-EP) | Quarterly ASV scan |
+| Client has any web application | Recommended | Quarterly ASV scan |
+| Custom Catalyst endpoints handling payment webhooks | Recommended | Quarterly ASV scan |
+
+### Approved Scanning Vendor (ASV) Options
+
+If scans are required or recommended:
+- Qualys
+- Rapid7
+- Tenable
+- SecurityMetrics (popular for small businesses)
+
+---
+
+## Penetration Testing Requirements
+
+### SAQ-A Requirements
+
+- SAQ-A does **NOT** explicitly require penetration testing
+- **However**: PCI-DSS v4.0 Requirement 11.4 strongly recommends it
+- **CloudStream recommendation**: Annual penetration test of the payment integration flow
+
+### What to Test
+
+| Test Area | Scope | Frequency |
+|---|---|---|
+| Payment redirect flow | Ensure no card data leakage | Annual |
+| Webhook endpoint | Authentication, injection | Annual |
+| Token storage forms | Access controls, exposure | Annual |
+| Creator portal | Session management, auth | Annual |
+| Error handling | Ensure errors don't expose card data | Annual |
+
+---
+
+## Incident Response Plan
+
+### Payment Security Incident Categories
+
+| Category | Example | Response Time |
+|---|---|---|
+| **Critical** | Suspected card data breach | Immediate (within 1 hour) |
+| **High** | Unauthorized access to payment tokens | Within 4 hours |
+| **Medium** | Payment webhook failures | Within 24 hours |
+| **Low** | Failed payment processing | Next business day |
+
+### Incident Response Steps
+
+1. **Detect**: Identify the incident (monitoring, alert, customer report)
+2. **Contain**: Isolate affected systems, disable compromised credentials
+3. **Assess**: Determine scope -- was actual card data exposed?
+4. **Notify**: Alert payment processor, client, acquiring bank (if breach confirmed)
+5. **Investigate**: Root cause analysis using audit logs
+6. **Remediate**: Fix the vulnerability, implement controls
+7. **Report**: Document findings, update incident log
+8. **Review**: Post-incident review, update procedures
+
+### Incident Response Contact List
+
+```
+| Role | Contact | When to Notify |
+|---|---|---|
+| CloudStream Security Lead | security@cloudstreamsoftware.com | All incidents |
+| Client IT Contact | [per client] | High+ incidents |
+| Zoho Security | security@zohocorp.com | If Zoho platform involved |
+| Acquiring Bank | [per client's bank] | Confirmed breaches only |
+| PCI Forensic Investigator | [retain on standby] | Confirmed breaches only |
+| Legal Counsel | [per client] | High+ incidents |
+```
+
+---
+
+## Compliance Evidence Collection
+
+### Annual Evidence Package
+
+Collect and maintain these artifacts for each client annually:
+
+| Evidence | Source | Format |
+|---|---|---|
+| Completed SAQ-A form | PCI SSC template | PDF (signed) |
+| Attestation of Compliance | Generated from SAQ-A | PDF (signed) |
+| Provider AoC (Zoho) | Request from Zoho | PDF |
+| Provider AoC (Stripe, if used) | Stripe Dashboard | PDF |
+| Payment data flow diagram | CloudStream documentation | PDF/PNG |
+| Security policy | Client compliance folder | PDF |
+| Incident response plan | Client compliance folder | PDF |
+| Access review evidence | Quarterly review logs | PDF/CSV |
+| Change management records | Creator Change_Requests form | CSV export |
+| Webhook security config | Catalyst function config | Screenshot |
+
+---
+
+## ASV Scan Scheduling
+
+If quarterly scans are required:
+
+| Quarter | Scan Window | Results Due | Remediation Due |
+|---|---|---|---|
+| Q1 | Jan 1-31 | Feb 15 | Mar 1 |
+| Q2 | Apr 1-30 | May 15 | Jun 1 |
+| Q3 | Jul 1-31 | Aug 15 | Sep 1 |
+| Q4 | Oct 1-31 | Nov 15 | Dec 1 |
+
+### Scan Failure Response
+
+1. Review scan findings (categorized by CVSS score)
+2. CVSS 4.0+ (Medium+): Must remediate for passing scan
+3. Rescan after remediation
+4. Document all findings and remediation in compliance folder
+5. Maintain scan history for 12+ months
+
+---
+
+## Maintaining Compliance Year-Round
+
+### Monthly PCI Maintenance Tasks
+
+- [ ] Review payment processing logs for anomalies
+- [ ] Verify hosted payment page is functioning correctly
+- [ ] Check webhook endpoint health and response times
+- [ ] Review any new Creator forms/fields for accidental card data fields
+- [ ] Verify MFA is enforced for all users with payment system access
+- [ ] Review and disable unnecessary user accounts
+
+### Quarterly PCI Maintenance Tasks
+
+- [ ] Conduct access review for payment-related forms
+- [ ] Review change log for payment flow modifications
+- [ ] Verify payment provider's compliance status (check for breach announcements)
+- [ ] Run ASV scan (if applicable)
+- [ ] Review and update incident response plan contacts
+
+### Annual PCI Maintenance Tasks
+
+- [ ] Complete SAQ-A self-assessment
+- [ ] Obtain updated AoC from payment providers
+- [ ] Review and update security policies
+- [ ] Conduct payment flow penetration test (recommended)
+- [ ] Update data flow diagram if architecture changed
+- [ ] Submit attestation to acquiring bank
+- [ ] Archive previous year's compliance evidence
+
+> **WARNING**: PCI compliance is continuous, not a once-per-year event. A compliance gap discovered mid-year can result in fines from the acquiring bank and potential loss of payment processing privileges.

package/skills/compliance-patterns/pci-dss/tokenization-patterns.md

@@ -0,0 +1,382 @@
+# PCI-DSS Tokenization Patterns
+
+## Overview
+
+PCI-DSS compliance requires that cardholder data is protected throughout its lifecycle. The primary strategy for Zoho-based implementations is **scope reduction via tokenization** -- never handling raw card data directly. Zoho Payments provides tokenization through hosted payment pages, ensuring that card numbers never touch CloudStream or client infrastructure.
+
+> **WARNING**: If raw card data (full PAN, CVV, or magnetic stripe data) ever touches your Zoho Creator application, your client is in PCI-DSS scope for the full 300+ requirement set. Hosted pages reduce this to SAQ-A (22 requirements). This is non-negotiable.
+
+---
+
+## Zoho Payments API for Tokenization
+
+### How Tokenization Works
+
+```
+Customer Browser
+    |
+    | (1) Redirect to Zoho Checkout hosted page
+    v
+Zoho Hosted Payment Page (Zoho's PCI-certified environment)
+    |
+    | (2) Customer enters card details (NEVER touches your systems)
+    v
+Zoho Payment Gateway
+    |
+    | (3) Card tokenized, token returned
+    v
+Zoho Creator (receives TOKEN only, never raw card data)
+    |
+    | (4) Store token for future charges
+    v
+Your Application (token-based operations only)
+```
+
+### Key Principle
+
+**Your code, your servers, your Creator forms NEVER see raw card numbers.** You only ever interact with tokens that represent the card.
+
+---
+
+## Hosted Payment Pages (Zoho Checkout)
+
+### Implementation Pattern
+
+```deluge
+// ============================================================
+// FUNCTION: createPaymentSession
+// PURPOSE: Generate a hosted payment page URL for the customer
+// CONTEXT: Called when customer is ready to pay
+// ============================================================
+
+Map createPaymentSession(int invoiceId, Decimal amount, String customerEmail)
+{
+    invoice = zoho.creator.getRecordById("app", "Invoices", invoiceId);
+
+    // Create payment session via Zoho Payments API
+    paymentData = Map();
+    paymentData.put("amount", amount * 100);  // Amount in cents
+    paymentData.put("currency", "USD");
+    paymentData.put("customer_email", customerEmail);
+    paymentData.put("description", "Invoice #" + invoice.get("Invoice_Number"));
+    paymentData.put("reference_id", invoiceId.toString());
+    paymentData.put("success_url", "https://client-app.zohocreatorportal.com/payment-success");
+    paymentData.put("cancel_url", "https://client-app.zohocreatorportal.com/payment-cancelled");
+
+    // For recurring: request tokenization consent
+    paymentData.put("payment_mode", "tokenize");  // Stores card as token
+
+    response = invokeurl [
+        url: "https://payments.zoho.com/api/v1/sessions"
+        type: POST
+        body: paymentData.toString()
+        connection: "zoho_payments_connection"
+    ];
+
+    return {
+        "session_id": response.get("session_id"),
+        "checkout_url": response.get("checkout_url"),
+        "expires_at": response.get("expires_at")
+    };
+}
+```
+
+### Hosted Page Configuration
+
+| Setting | Value | Rationale |
+|---|---|---|
+| Payment methods | Cards, ACH (as needed) | Limit to required methods |
+| Card storage consent | Required for recurring | Customer must opt-in |
+| 3D Secure | Enabled | Reduces fraud, may reduce scope |
+| Address collection | Based on business need | AVS verification |
+| Custom branding | Client logo + colors | Professional appearance |
+| Redirect URLs | Client portal pages | Return to application |
+| Webhook URL | Catalyst function endpoint | Process payment events |
+
+---
+
+## What You CAN and CANNOT Store
+
+> **WARNING**: Storing prohibited data elements -- even accidentally, even in logs -- puts you in full PCI-DSS scope. Review every form field, every log entry, every error message.
+
+### Prohibited (NEVER Store)
+
+| Data Element | Also Known As | Why Prohibited |
+|---|---|---|
+| Full PAN | Card number (all 16 digits) | PCI-DSS Requirement 3.4 |
+| CVV/CVC/CID | Security code (3-4 digits) | PCI-DSS Requirement 3.2.2 |
+| Magnetic stripe data | Track 1 / Track 2 | PCI-DSS Requirement 3.2.1 |
+| PIN / PIN block | Personal Identification Number | PCI-DSS Requirement 3.2.3 |
+
+### Permitted (Safe to Store)
+
+| Data Element | Example | Storage Guidelines |
+|---|---|---|
+| Token | `tok_abc123xyz789` | Primary identifier for future charges |
+| Last 4 digits | `****4242` | Display purposes, customer identification |
+| Expiry month/year | `12/2027` | Proactive card expiry notifications |
+| Cardholder name | `John Smith` | Reference (but treat as PII) |
+| Card brand | `Visa`, `Mastercard` | Display and routing |
+| Payment status | `succeeded`, `failed` | Transaction tracking |
+| Transaction ID | `txn_xyz789` | Reference for refunds/disputes |
+
+### Creator Form: Payment_Tokens
+
+```
+Form: Payment_Tokens
+Fields:
+  - Token_ID (Auto-number)
+  - Customer_ID (Lookup to Customers)
+  - Payment_Token (Single Line - the token from Zoho Payments)
+  - Card_Last_Four (Single Line - 4 characters max)
+  - Card_Brand (Picklist: Visa/Mastercard/Amex/Discover)
+  - Expiry_Month (Number - 1-12)
+  - Expiry_Year (Number - 2024-2040)
+  - Cardholder_Name (Single Line)
+  - Is_Default (Checkbox)
+  - Token_Created_Date (DateTime)
+  - Token_Status (Picklist: Active/Expired/Revoked)
+  - Last_Used_Date (DateTime)
+  - Customer_Consent_Date (DateTime)
+  - Consent_Method (Picklist: Checkout Page/API/In-Person)
+```
+
+> **WARNING**: NEVER add fields like "Card_Number" or "CVV" to ANY form. Even creating the field without populating it suggests a misunderstanding of PCI scope and will concern auditors.
+
+---
+
+## Recurring Charge Patterns Using Tokens
+
+### Subscription Billing
+
+```deluge
+// ============================================================
+// FUNCTION: processRecurringCharge
+// PURPOSE: Charge a stored token for subscription renewal
+// CONTEXT: Called by scheduled workflow on billing date
+// ============================================================
+
+Map processRecurringCharge(int subscriptionId)
+{
+    startTime = zoho.currenttime;
+    subscription = zoho.creator.getRecordById("app", "Subscriptions", subscriptionId);
+    token = zoho.creator.getRecordById("app", "Payment_Tokens", subscription.get("Payment_Token_ID"));
+
+    // Verify token is still active
+    if (token.get("Token_Status") != "Active") {
+        // Notify customer of expired payment method
+        notifyExpiredCard(subscription);
+        return {"status": "failed", "reason": "token_inactive"};
+    }
+
+    // Check expiry date
+    if (isCardExpired(token)) {
+        zoho.creator.updateRecord("app", "Payment_Tokens", token.get("ID"), {"Token_Status": "Expired"});
+        notifyExpiredCard(subscription);
+        return {"status": "failed", "reason": "card_expired"};
+    }
+
+    // Process charge via Zoho Payments
+    chargeData = Map();
+    chargeData.put("amount", subscription.get("Amount") * 100);
+    chargeData.put("currency", "USD");
+    chargeData.put("token", token.get("Payment_Token"));
+    chargeData.put("description", "Subscription renewal - " + subscription.get("Plan_Name"));
+    chargeData.put("reference_id", subscriptionId.toString());
+
+    response = invokeurl [
+        url: "https://payments.zoho.com/api/v1/charges"
+        type: POST
+        body: chargeData.toString()
+        connection: "zoho_payments_connection"
+    ];
+
+    if (response.get("status") == "succeeded") {
+        // Record successful payment
+        insert into Payment_History [
+            Subscription_ID = subscriptionId,
+            Amount = subscription.get("Amount"),
+            Transaction_ID = response.get("transaction_id"),
+            Status = "Succeeded",
+            Payment_Date = zoho.currentdate,
+            Token_Last_Four = token.get("Card_Last_Four")
+        ];
+
+        return {"status": "succeeded", "transaction_id": response.get("transaction_id")};
+    } else {
+        // Handle decline
+        handlePaymentDecline(subscription, response);
+        return {"status": "failed", "reason": response.get("failure_reason")};
+    }
+}
+```
+
+### Retry Logic for Failed Recurring Charges
+
+| Attempt | Timing | Action on Failure |
+|---|---|---|
+| 1st attempt | Billing date | Retry in 3 days |
+| 2nd attempt | Billing + 3 days | Retry in 5 days, email customer |
+| 3rd attempt | Billing + 8 days | Retry in 5 days, email + SMS |
+| 4th attempt | Billing + 13 days | Final notice, suspend service in 2 days |
+| Final | Billing + 15 days | Suspend service, require manual payment |
+
+---
+
+## Refund Processing
+
+```deluge
+// ============================================================
+// FUNCTION: processRefund
+// PURPOSE: Issue a refund against a previous charge
+// CONTEXT: Called from admin action on Payment_History form
+// ============================================================
+
+Map processRefund(int paymentId, Decimal refundAmount, String reason)
+{
+    payment = zoho.creator.getRecordById("app", "Payment_History", paymentId);
+
+    // Validate refund amount
+    if (refundAmount > payment.get("Amount")) {
+        return {"status": "error", "message": "Refund amount exceeds original charge"};
+    }
+
+    refundData = Map();
+    refundData.put("transaction_id", payment.get("Transaction_ID"));
+    refundData.put("amount", refundAmount * 100);  // Cents
+    refundData.put("reason", reason);
+
+    response = invokeurl [
+        url: "https://payments.zoho.com/api/v1/refunds"
+        type: POST
+        body: refundData.toString()
+        connection: "zoho_payments_connection"
+    ];
+
+    if (response.get("status") == "succeeded") {
+        insert into Payment_History [
+            Subscription_ID = payment.get("Subscription_ID"),
+            Amount = refundAmount * -1,  // Negative for refund
+            Transaction_ID = response.get("refund_id"),
+            Status = "Refunded",
+            Payment_Date = zoho.currentdate,
+            Refund_Reason = reason,
+            Original_Payment_ID = paymentId
+        ];
+    }
+
+    return response;
+}
+```
+
+---
+
+## Payment Status Webhooks
+
+### Webhook Handler (Catalyst Function)
+
+```javascript
+// File: functions/payment_webhook/index.js
+// Receives webhook events from Zoho Payments
+
+module.exports = async (req, res, context) => {
+  const event = req.body;
+
+  // Verify webhook signature (CRITICAL for security)
+  if (!verifyWebhookSignature(req.headers['x-zoho-signature'], req.body)) {
+    console.error('Invalid webhook signature');
+    return res.status(401).send('Unauthorized');
+  }
+
+  switch (event.event_type) {
+    case 'payment.succeeded':
+      await handlePaymentSuccess(event.data);
+      break;
+    case 'payment.failed':
+      await handlePaymentFailure(event.data);
+      break;
+    case 'refund.succeeded':
+      await handleRefundSuccess(event.data);
+      break;
+    case 'token.expired':
+      await handleTokenExpired(event.data);
+      break;
+    case 'dispute.created':
+      await handleDisputeCreated(event.data);
+      break;
+    default:
+      console.log(`Unhandled event type: ${event.event_type}`);
+  }
+
+  res.status(200).send('OK');
+};
+```
+
+### Webhook Events to Handle
+
+| Event | Action | Priority |
+|---|---|---|
+| `payment.succeeded` | Update invoice status, send receipt | Critical |
+| `payment.failed` | Log failure, notify customer | Critical |
+| `refund.succeeded` | Update payment record, notify customer | High |
+| `token.expired` | Mark token inactive, notify customer | High |
+| `dispute.created` | Alert admin, freeze account if needed | Critical |
+| `payout.completed` | Update settlement records | Medium |
+
+---
+
+## PCI Scope Reduction via Hosted Pages
+
+### Scope Comparison
+
+| Approach | PCI Scope | Requirements | Audit Effort |
+|---|---|---|---|
+| **Hosted pages (Zoho Checkout)** | SAQ-A (minimal) | 22 requirements | Self-assessment |
+| Direct card input (your forms) | SAQ-D (full) | 300+ requirements | On-site audit |
+| JavaScript tokenization (your page) | SAQ-A-EP | ~140 requirements | Moderate audit |
+| API direct card processing | SAQ-D (full) | 300+ requirements | On-site audit |
+
+> **WARNING**: The ONLY approach CloudStream should implement is hosted pages (SAQ-A). Any other approach dramatically increases compliance burden and liability.
+
+---
+
+## Zoho Payments vs. Stripe for the Zoho Ecosystem
+
+| Feature | Zoho Payments | Stripe |
+|---|---|---|
+| Native Zoho integration | YES - first-party | Requires custom integration |
+| Hosted checkout pages | YES (Zoho Checkout) | YES (Stripe Checkout) |
+| Tokenization | YES | YES |
+| Recurring billing | YES (Zoho Subscriptions) | YES (Stripe Billing) |
+| SAQ-A eligible | YES (hosted pages) | YES (hosted pages) |
+| US availability | YES | YES |
+| International | Limited markets | 195+ countries |
+| Pricing | 2.9% + $0.30 (US cards) | 2.9% + $0.30 (US cards) |
+| Zoho Books sync | Native | Requires Zoho Flow/custom |
+| PCI compliance docs | Available on request | Self-service in dashboard |
+| Creator integration | Direct API connection | Custom API integration |
+
+### Recommendation
+
+- **Use Zoho Payments when**: Client is fully in the Zoho ecosystem, US-focused, wants native Books/Invoice integration
+- **Use Stripe when**: International transactions needed, advanced fraud detection required, or client has existing Stripe infrastructure
+- **Either way**: ALWAYS use hosted pages for SAQ-A scope reduction
+
+---
+
+## Implementation Checklist
+
+- [ ] Zoho Payments account configured for client
+- [ ] Hosted payment page designed with client branding
+- [ ] Success/cancel redirect URLs configured
+- [ ] Webhook endpoint deployed (Catalyst function)
+- [ ] Webhook signature verification implemented
+- [ ] Payment_Tokens form created (NO prohibited fields)
+- [ ] Payment_History form created
+- [ ] Recurring charge workflow configured (if applicable)
+- [ ] Refund process documented and tested
+- [ ] Token expiry notification workflow active
+- [ ] PCI SAQ-A self-assessment completed
+- [ ] No raw card data in any form, log, or error message
+- [ ] Payment flows tested end-to-end in sandbox
+- [ ] Client trained on payment dashboard access