Summary of Stripe Implementation Analysis (#956)

Current Status in Production

The system currently implements two distinct Stripe workflows:

1. User to Platform (Admin) Subscription:

   • Goal: Users subscribe to the Platform (Admin) for system access.
   • Implementation: Direct Stripe API using the platform’s secret key.
   • Key Files: StripePaymentSubscription.php, Subscription model, and UserPlan table.
   • Data: Users are registered as Customers in the Platform’s Stripe account.

2. Customer to User One-time Payment:

   • Goal: Customers pay Users for services (one-off payments).
   • Implementation: Stripe Connect using Destination Charges.
   • Key Files: StripeConnectPayment.php, Order model, and UserPaymentSetting (storing stripe_connect_id).
   • Fees: Commission is taken via application_fee_amount.

New Requirement: Customer to User Subscription

Can it be done with Stripe? Yes.

Since the system already uses Stripe Connect for one-time payments, extending it to subscriptions is straightforward and uses a similar architecture.

Technical Feasibility & Strategy

• Architecture: Use Stripe Connect Subscriptions with Destination Charges.
• Mechanism: Create the subscription on the Platform account, but direct the recurring funds to the User’s Connected Account using transfer_data[destination].

Implementation Path

1. Stripe API (Connect): Extend the current Subscription::create call to include:
   • transfer_data[destination]: The User’s stripe_connect_id.
   • application_fee_percent: For recurring commission on each subscription cycle.
2. Database:
   • Add a new customer_subscriptions table to link Customers to Users/Services (modeled after the existing subscriptions table).
   • Leverage Type::SUBSCRIPTION = 3 in the Service model’s enum.
3. Webhook Handlers:
   • Add handlers for recurring events like invoice.paid, customer.subscription.deleted, and customer.subscription.updated within the Connect webhook flow.
4. UI/UX:
   • Update the Customer-facing payment flow to handle recurring subscription initiation.

Verdict: The existing infrastructure for Stripe Connect (storing stripe_connect_id) and Subscriptions (using the standard Stripe API) provides a solid foundation for this feature without requiring a major architectural redesign.

Progress Update

Status: COMPLETED

• Frontend: Successfully implemented a 3-step customer checkout flow (Select -> Confirm & Payment -> Complete). Integrated React Stripe Elements directly into the confirmation screen to tokenize credit cards securely.
• Backend: Implemented SubscriptionInteractor for orders and payments to create Stripe Subscriptions using the Stripe Connect API with Destination Charges, automatically syncing customers and accurately routing funds. Webhook handling is in place to manage the subscription lifecycle.