> For the complete documentation index, see [llms.txt](https://help.flycode.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.flycode.com/failed-payment-outreach/delivery-strategy.md). # Delivery Strategy FlyCode's recovery email delivery strategy: local-time sending, faster action-specific cadences for hard declines, CAN-SPAM and GDPR compliance, how it differs from Stripe and ProfitWell emails, and 9 When and how a recovery message is delivered matters as much as what it says. FlyCode's delivery strategy is built on behaviour, timing and rules rather than a fixed drip. ## What do you mean by "local time delivery"? FlyCode detects each customer's time zone from the card and billing data and schedules sends for the hours when that customer is most likely to open and act, typically mid-morning local time. A renewal that fails overnight in the customer's region is not announced with a 2 a.m. email that gets buried under the morning's mail. Local-time delivery applies to every message in the sequence and to SMS. ## How does FlyCode handle hard declines? For hard declines the customer must act, so the strategy changes. FlyCode makes the cadence faster than for soft declines, uses dynamic templates with the specific action required ("update your card", "verify with your bank"), links to a one-click payment update page, and sequences follow-ups based on the customer's past engagement, so a customer who opened but did not act gets a different next message from one who never opened. Where a backup payment method is on file, FlyCode charges it first and only messages if that also fails. See [Hard Declines & Backup Logic](https://help.flycode.com/ai-payment-recovery/hard-declines-and-backup-logic). ## Is this compliant with privacy and email laws? Yes. FlyCode follows CAN-SPAM, GDPR and the other major privacy and email regulations by default. Recovery emails are transactional messages about an existing paid relationship, which is the category these laws treat most permissively, but FlyCode still applies the safeguards: accurate sender identity, your physical address where required, no misleading subject lines, processing of customer data only for the purpose of recovering the payment, and data handling under your data processing agreement. Sending from your authenticated domain also satisfies the sender authentication requirements that mailbox providers now enforce. ## How is FlyCode's outreach different from Stripe or ProfitWell emails? FlyCode's communications are driven by models that coordinate emails with retries. It does not email immediately after a soft decline (that reduces voluntary churn), it runs a distinct schedule for hard declines, it sends at the customer's local time, and it uses plain transactional templates from infrastructure with a 95-plus sender score. Stripe Billing's default recovery settings send an email every time a payment is retried, so a customer can receive up to eight emails for one invoice. ProfitWell applies basic per-retry email logic. | | FlyCode | Without FlyCode (Stripe defaults) | | ---------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------- | | Number of emails | Model-based, coordinated with retries | One on every retry, up to 8 | | Soft declines | Retries first, email only if retries fail | Email at each attempt | | Timing | Customer's local time | Whenever the retry runs | | Format and deliverability | Plain transactional, 95-plus sender score | Varies | | Multiple contacts in a B2B account | Can message different users in the customer's organization | Single billing email | | Payment page | Processor's native page with all local payment options | Native page (Stripe) or custom page with limited options (ProfitWell) | | Analytics | Full-funnel view by customer and by email | Basic | ## What does deliverability look like? Emails are transactional-only and typically achieve a sender score of 95 or higher. FlyCode uses transactional sending infrastructure rather than a marketing platform, enforces SPF and DKIM alignment with your domain, and optimizes the sending subdomain and IP reputation. Open, click and payment-update rates are visible per email in the dashboard so you can see which step in the sequence recovers the most. ## Related * [Messaging Customization](https://help.flycode.com/failed-payment-outreach/messaging-customization) * [How does FlyCode handle customer emails compared with Stripe's defaults?](https://help.flycode.com/handling-failed-payments/coordinating-messaging-with-recovery) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.flycode.com/failed-payment-outreach/delivery-strategy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.