Skip to main content

Stripe

Stripe can be connected to SolydFlow to process payments for customers in supported markets.

With Stripe connected, SolydFlow provides the revenue infrastructure around Stripe transactions while your application interacts with SolydFlow rather than implementing Stripe-specific payment logic throughout the application.

Your Application
       ↓
   SolydFlow
       ↓
     Stripe
       ↓
Payment Network

When to Use Stripe​

Stripe is particularly useful when your application needs to serve customers in international markets and use Stripe-supported payment methods.

For example:

Application
    ↓
SolydFlow
    ↓
Stripe
    ↓
International Customers

Stripe can therefore be one of several providers connected to the same SolydFlow project.

For African markets, you may also consider providers such as:

How Stripe Fits Into SolydFlow​

The integration follows the same provider architecture used throughout SolydFlow.

                 SolydFlow
                     │
              Stripe Connection
                     │
          ┌──────────┴──────────┐
          ↓                     ↓
     Payment Flow          Webhooks
          │                     │
          ↓                     ↓
       Stripe              SolydFlow
          │                     │
          └──────────┬──────────┘
                     ↓
               Transaction
                     ↓
                Entitlement

Stripe remains responsible for processing the payment.

SolydFlow manages the application-facing revenue lifecycle around that payment.

What Stripe Handles​

Stripe is responsible for the Stripe-side payment operation.

Depending on your Stripe configuration and the payment method being used, this can include:

  • Payment processing
  • Supported payment methods
  • Stripe checkout/payment interfaces
  • Stripe-side payment state
  • Stripe-side customer and payment records
  • Stripe webhooks
  • Refunds and other Stripe-supported payment operations

Stripe's capabilities and requirements can change, so consult Stripe's documentation for provider-specific behavior.

What SolydFlow Handles​

SolydFlow sits above Stripe to provide a consistent revenue layer for your application.

This can include:

  • Associating Stripe payments with your SolydFlow products and packages
  • Tracking the resulting transaction
  • Processing provider events
  • Recovering transactions when expected events are missing
  • Verifying transaction state
  • Maintaining a unified transaction view
  • Managing entitlements
  • Supporting routing and failover where configured
Stripe Payment
      ↓
Stripe Event
      ↓
SolydFlow
      ↓
Transaction State
      ↓
Entitlement
      ↓
Application Access

Prerequisites​

Before connecting Stripe to SolydFlow, you should have:

  1. A Stripe account
  2. The required Stripe credentials
  3. A SolydFlow project
  4. Products and packages configured in SolydFlow
  5. A clear understanding of which markets you intend to serve

Your Stripe account must also be configured appropriately for the business and payment methods you intend to use.

Connecting Stripe​

The general setup flow is:

Create Stripe Account
        ↓
Configure Stripe
        ↓
Obtain Required Credentials
        ↓
Connect Stripe to SolydFlow
        ↓
Configure Products / Packages
        ↓
Configure Webhooks
        ↓
Test
        ↓
Go Live

The exact credentials and configuration fields depend on the current SolydFlow integration.

Stripe Credentials​

Stripe integrations commonly use credentials to authenticate requests.

Treat secret credentials as sensitive information.

❌ Do not expose secret credentials
   in frontend code.

✅ Keep secret credentials
   in secure server-side configuration.

Your SolydFlow project should be configured with the appropriate credentials through the supported provider configuration mechanism.

See:

API Keys →

Credential Security →

Public vs Secret Credentials​

Some provider credentials are designed to be exposed to a client application, while secret credentials must remain protected.

For example:

Public Credential
     ↓
May be used by client-side payment flow

Secret Credential
     ↓
Must remain server-side / protected

Do not assume that a credential is safe to expose simply because it is associated with Stripe.

Follow the credential requirements for the specific Stripe integration being used.

Products and Packages​

Your commercial configuration should be defined in SolydFlow.

For example:

Product
└── Pro
    ├── Monthly
    └── Annual

You can then associate the appropriate payment-provider configuration with the purchasing flow.

This keeps the application's monetization model separate from the provider implementation.

See:

Products →

Packages →

Products and Packages →

Stripe and Paywalls​

A customer may encounter your application's paywall before the Stripe payment flow begins.

Customer
   ↓
Application
   ↓
SolydFlow Paywall
   ↓
Package
   ↓
Stripe Payment

The paywall communicates the product and pricing configured for the customer.

Stripe then processes the payment.

See:

Paywalls →

Stripe Webhooks​

Stripe can send events to notify your system about changes to payment-related objects.

In the SolydFlow architecture:

Stripe
   ↓
Webhook Event
   ↓
SolydFlow
   ↓
Transaction Processing

Webhook processing is important because payment state can change independently of the application's immediate request.

For example:

Customer
   ↓
Payment
   ↓
Stripe
   ↓
Webhook

The webhook provides an important signal that SolydFlow can use when determining the transaction state.

See:

Provider Webhooks →

Missing Stripe Webhooks​

A successful Stripe payment does not guarantee that your application will immediately receive the expected webhook.

For example:

Customer
   ↓
Stripe Payment
   ↓
Successful
   ↓
Webhook
   X

The payment may have succeeded even though the expected event was not received.

SolydFlow's recovery and truth layers are designed to address this type of situation.

Stripe
   ↓
Payment Successful
   ↓
Expected Event Missing
   ↓
Recovery
   ↓
Verification
   ↓
Correct Transaction State

See:

Failed Webhooks →

Transaction Recovery →

Transaction Verification →

Stripe Transaction State​

Stripe has its own representation of payment state.

SolydFlow also maintains a transaction lifecycle for your application.

These states may not always update at exactly the same time.

For example:

Stripe
└── Payment Successful

SolydFlow
└── Processing

SolydFlow can use available provider information and transaction events to determine the appropriate application-facing state.

Stripe State
      +
SolydFlow State
      ↓
Transaction Truth

See:

Transaction States →

State Mismatches →

Stripe and Transaction Recovery​

A transaction can become difficult to resolve when the expected payment event does not reach the application.

For example:

Application
    ↓
Purchase Started
    ↓
Stripe
    ↓
Payment Completed
    ↓
Webhook Missing

Rather than forcing every application to implement its own provider-specific recovery process, SolydFlow can handle the recovery layer.

Transaction
    ↓
Recovery
    ↓
Provider Verification
    ↓
Resolved State
    ↓
Entitlement

See:

Recover →

Stripe and the Transaction Ledger​

A Stripe transaction is one source of information about what happened during a payment.

SolydFlow can maintain a unified transaction record around the application revenue lifecycle.

Stripe
   ↓
Provider Transaction
   ↓
SolydFlow Transaction
   ↓
Unified Revenue Record

This becomes particularly useful when your project uses multiple payment providers.

             SolydFlow
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
    Stripe    Paystack  Flutterwave
       │         │         │
       └─────────┼─────────┘
                 ↓
          Unified Ledger

See:

Transaction Ledger →

Reconciliation →

Using Stripe Alongside Other Providers​

You do not necessarily need to choose between Stripe and every other provider.

For example:

                  SolydFlow
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       Stripe      Paystack    Flutterwave
          │           │           │
         US          Nigeria      Africa

This can allow your application to use providers according to market, payment method, or your revenue strategy.

The exact routing behavior depends on your configuration.

See:

Smart Routing →

Provider Failover →

Stripe Failover​

If multiple providers are configured, Stripe can participate in a resilient provider architecture.

Conceptually:

Payment Request
      ↓
   SolydFlow
      ↓
Preferred Provider
      ↓
   Unavailable
      ↓
Alternative Provider

Failover should only be used where the payment flow and provider capabilities support it safely.

Payment attempts must not be duplicated simply because a provider response was delayed or unavailable.

This is one reason transaction state and verification are important parts of the SolydFlow architecture.

See:

Provider Failover →

Testing Stripe​

Use Stripe's supported testing environment before processing live payments.

A typical development flow is:

Development
    ↓
Stripe Test Mode
    ↓
SolydFlow Sandbox
    ↓
Test Purchase
    ↓
Webhook Test
    ↓
Recovery Test
    ↓
Production

Test at least:

  • Successful payments
  • Failed payments
  • Pending payments
  • Webhook delivery
  • Missing webhook scenarios
  • Transaction recovery
  • Transaction verification
  • Entitlement updates

See:

Test Transactions →

Simulate Failures →

Testing Recovery →

Production Checklist​

Before processing live payments through Stripe, verify:

Stripe​

  • Your Stripe account is configured for your business
  • Production credentials are being used
  • The required payment methods are enabled
  • The intended currencies are supported
  • Stripe webhook configuration is correct

SolydFlow​

  • Stripe is connected to the correct project
  • Products are configured correctly
  • Packages are configured correctly
  • Prices are correct
  • Paywalls display the intended offering
  • Webhook processing is configured
  • Recovery has been tested
  • Entitlements behave correctly

Security​

  • Secret credentials are protected
  • Webhook signatures are verified
  • Production secrets are not included in client-side code
  • Access to provider configuration is restricted

See:

Production Checklist →

Stripe Refunds and Payment Changes​

Stripe supports payment operations such as refunds according to its capabilities and your account configuration.

When a payment changes after the original transaction, the application-facing revenue state may also need to be updated.

The important distinction is:

Stripe Payment Event
       ↓
SolydFlow
       ↓
Transaction State
       ↓
Entitlement / Access

Do not treat the original successful payment as the only event that can affect a customer's revenue lifecycle.

Provider events may require additional processing.

Compliance​

Stripe remains responsible for the provider-side requirements associated with its payment infrastructure.

SolydFlow does not remove your responsibility to understand the requirements that apply to your business, application, customers, and markets.

If you are operating across multiple countries, payment processing can involve additional considerations such as:

  • Taxes
  • Consumer regulations
  • Business registration
  • Payment regulations
  • Data protection
  • Local payment requirements

See:

Compliance →

Tax and Compliance →

Troubleshooting​

If a Stripe payment does not produce the expected application result, start by determining where the flow stopped.

Customer
   ↓
Paywall
   ↓
Purchase
   ↓
Stripe
   ↓
Webhook
   ↓
SolydFlow
   ↓
Transaction
   ↓
Entitlement

Useful questions include:

  1. Did the customer start the purchase?
  2. Did Stripe receive the payment request?
  3. What state does Stripe report?
  4. Was the expected webhook generated?
  5. Did SolydFlow receive the webhook?
  6. What transaction state does SolydFlow show?
  7. Was the transaction verified?
  8. Was the entitlement granted?

See:

Troubleshooting →

Key Principle​

Stripe processes the payment. SolydFlow manages the revenue flow around the payment.

Your application should not need to duplicate Stripe-specific transaction, webhook, recovery, and reconciliation logic throughout its codebase.

Your Application
       ↓
   SolydFlow
       ↓
     Stripe
       ↓
   Payment
       ↓
Transaction
       ↓
Entitlement
       ↓
Application Access

This allows Stripe to remain the payment processor while SolydFlow provides a consistent revenue infrastructure for your application.