Take the money inside the system. Not in a separate tool.

Your CRM stops where the money starts.

Every CRM on the market does roughly the same thing: it tracks the deal up to the moment the customer says yes — and then hands you off to a different tool to actually collect the money. You build the quote in HubSpot, then open Stripe in another tab. You confirm the deal in Pipedrive, then send a separate Square link. You close the customer in Salesforce, then reconcile manually with QuickBooks two weeks later.

That gap between "yes" and "paid" is where money goes missing. The customer says yes Tuesday. The invoice goes out Thursday. The customer's enthusiasm has cooled by Friday. The follow-up to make sure they paid happens next Wednesday because nobody owns it. Three weeks later the bookkeeper notices the invoice is overdue. Some percentage of those deals never close at all.

Aimee closes the gap. The CRM and the payment processor are the same system.

Net 30. Real invoice. Aimee chases the cash.

Some customers — especially in B2B — don't pay by card. They want to issue a Purchase Order against a Net 30 invoice. Their accounts team pays you by wire transfer or cheque, weeks later, on their own schedule.

Aimee handles this as a clean separate path. The customer replies "send me a PO" on the quote thread. You hit "Convert to PO Order" instead of "Complete Order." A small form captures:

• Customer PO number (for cross-reference)
• PO date
• Payment terms (Net 15 / Net 30 / Net 60 / Net 90 / COD / Prepaid / Custom)

Aimee converts the quote to an order with status awaiting external payment, pushes a tax-compliant Net 30 invoice into your accounting system, and waits. When accounts tells you the money's in, you click "Mark as paid," enter the wire reference, and Aimee:

• Updates the order status
• Syncs the paid status back to your accounting system
• Posts a payment received entry on the customer's timeline
• Stops the Net 30 reminder she had queued for day 32

If day 32 rolls around without the payment landing, Aimee proactively nudges you: "Acme's PO is two days overdue — want me to draft a polite chase email?"

Walk a customer to the payment page from a thread.

Customer emails aimee@yourcompany.com:

Aimee parses the request. She identifies Bob from his From: address, looks up the Henderson quote, sees a saved Stripe payment method on the account. Because money is moving, she doesn't just execute — she replies:

You click. The charge fires, the order converts, the invoice posts to Xero, the receipt goes back to the customer, and Aimee replies to confirm with the Stripe transaction ID. Total elapsed time: forty seconds.

Every money-moving action runs through this gate. Aimee never charges, refunds, or pushes money on her own initiative.

The card data we never see.

aimee.crm never stores card numbers. Ever. Card data either flows directly from the customer to the provider via tokenised client-side widgets (Stripe Elements, Braintree Hosted Fields, Adyen Drop-in, etc.) or via hosted payment pages on the provider's own infrastructure. The token comes back to us — never the card.

This puts the PCI compliance scope on the provider's side, not ours, for the link-based and redirect-based modes. For direct-charge modes (where some merchants prefer the customer never leave the app), you carry SAQ-D PCI scope as the merchant — same as you would with any direct-charge integration. We give you the choice; we don't hide the implications.

All provider API keys live encrypted at rest using AES-256-GCM with a per-deployment encryption key. Webhook payloads are cryptographically signed and validated — Stripe-Signature, HMAC-SHA512 for Authorize.net, HMAC-SHA256 for Checkout.com, Adyen, and Shopify, PayPal's verify-webhook-signature endpoint, and so on. Re-deliveries are handled idempotently — the same webhook firing twice never double-marks the order paid.