Ellipse Gradient for Header
Stripe logo

Integrate Stripe with Martini

Integrate Stripe with other enterprise systems by having Martini consume Stripe’s HTTPS REST APIs and receive selected Stripe webhook events through exposed services. Martini can create and retrieve Customers, PaymentIntents, Charges, Subscriptions, Invoices, Products, Prices, and other Stripe objects, then transform Stripe’s JSON payloads into canonical models for CRMs, ERP systems, databases, customer portals, or files. Workflows can use scheduled synchronization, cursor-based pagination, event reconciliation, idempotent writes, and retry handling. Martini can also validate webhook signatures, route events by type, and write transformed payment or billing data to databases, queues, files, or downstream APIs.

Stripe integration options at a glance

Integration pointSupported by Stripe?Common use casesHow Martini supports it
REST APIYesStripe provides an HTTPS REST API using JSON for creating, retrieving, updating, and listing Customers, PaymentIntents, Charges, Subscriptions, Invoices, Products, Prices, Refunds, and other resources. It supports cursor-based pagination and an Events API for event retrieval.Martini can consume Stripe REST endpoints, authenticate requests with securely stored keys, map request and response payloads, and expose reusable services or workflows. It can also apply pagination, idempotency, business rules, retries, and downstream delivery.
SOAP APINoStripe’s documented integration model is based on HTTPS REST APIs and JSON. SOAP is not documented as a Stripe integration mechanism.Martini should consume Stripe REST APIs rather than use SOAP for this integration. Martini can still expose SOAP services for other enterprise systems and transform those exchanges into Stripe REST requests where required.
WebhooksYes, for selected event typesStripe can deliver webhook events for selected payment, Checkout Session, customer, subscription, invoice, refund, dispute, payout, PaymentMethod, and Connect-related events. Deliveries can be retried, duplicated, or received out of order.Martini can expose a webhook-consuming REST service, validate Stripe signatures using the unmodified request body, route by event type, persist event IDs, and invoke asynchronous downstream workflows. It can retrieve the authoritative Stripe object when event freshness or ordering matters.
Events / triggersYes, for selected events and event retrievalStripe supports many webhook event types and an Events API for retrieving events. Coverage is event-type specific and does not represent a universal change-data-capture stream for every Stripe object.Martini can start workflows from received Stripe webhook events or schedule reconciliation using the Events API and object timestamps. Event IDs, persisted cursors, and deduplication records support restartable processing and missed-event recovery.
Bulk API / batch exportLimitedStripe supports some batch-oriented or bulk-related capabilities depending on the product area, but its standard REST API is generally resource- and request-oriented. A universal bulk API for all Stripe objects should not be assumed.Martini can implement controlled batch reads by combining Stripe list endpoints with cursor-based pagination and persisted checkpoints. It can transform batches and write them to databases, files, or downstream services while applying bounded retries.
Database accessNo direct Stripe database access documentedStripe does not provide documented direct database connectivity for synchronizing its internal data store. Database synchronization should use Stripe REST resources, webhook events, or the Events API.Martini can consume Stripe data through its APIs and write normalized Customers, Invoices, payment, subscription, or ledger data to supported databases. It can persist event IDs, object IDs, timestamps, and synchronization cursors for reconciliation.
File import/exportLimitedStripe provides file-related APIs for supported file purposes, but these are separate from ordinary JSON REST resources. General file-based exchange should not be assumed for every Stripe object or workflow.Martini can call supported Stripe file-related endpoints when applicable and transform returned data for enterprise file processing. It can also write processed Stripe data to files using Martini’s file-processing capabilities, where the target workflow requires it.
AuthenticationYesStandard server-to-server Stripe access uses secret or restricted API keys, with separate test-mode and live-mode credentials. Stripe Connect platforms may use OAuth and connected-account context, while webhooks use endpoint signing secrets.Martini can keep API keys, webhook signing secrets, OAuth values, and environment-specific configuration in deployment secrets. Workflows can apply account context consistently, keep test and live credentials isolated, and validate webhook signatures before processing.

How Stripe exposes data and business events

Stripe REST APIs

Stripe provides HTTPS REST APIs with JSON request and response payloads for creating, retrieving, updating, and listing business objects. The API includes resources such as Customers, PaymentIntents, Charges, Subscriptions, Invoices, Products, and Prices, with cursor-based pagination for list endpoints.

How This works in Martini

How this works in Martini: a workflow invokes the required Stripe endpoint using securely stored credentials, follows pagination when reading collections, maps JSON into an internal or target schema, and handles response status, validation errors, transient failures, and idempotent writes.

Example Martini workflow

Authenticate request
Call Stripe API
Follow cursors
Map JSON fields

Stripe Webhooks

Stripe supports webhook delivery for selected event types covering payments, Checkout Sessions, Customers, Subscriptions, Invoices, Refunds, Disputes, Payouts, PaymentMethods, and Connect operations. Deliveries may be retried, duplicated, or out of order.

How This works in Martini

How this works in Martini: Martini exposes a REST service for Stripe webhook delivery, validates the signature against the unmodified request body, persists the Stripe event ID, routes the event type, and starts downstream processing only after the event is safely accepted.

Example Martini workflow

Receive webhook
Validate signature
Deduplicate event
Route event type

Stripe Events API

Stripe provides an Events API that can be used to retrieve events for reconciliation. It complements webhook delivery but is not a substitute for real-time webhook processing, and it does not provide one universal change-data-capture stream for every object.

How This works in Martini

How this works in Martini: a scheduled Martini workflow retrieves relevant events or recently changed objects, stores a checkpoint or cursor, compares event IDs with durable processing records, and replays or reconciles items that were missed or failed.

Example Martini workflow

Schedule reconciliation
Retrieve events
Compare checkpoints
Replay discrepancies

Common Stripe integration patterns

Pattern 1

When to use this pattern

Use this pattern when successful payments should initiate fulfillment, order updates, or ERP actions. Stripe emits a selected payment or Checkout event, while Martini confirms the authoritative PaymentIntent, Charge, or Checkout Session before committing the downstream business action.

Data Flow
Stripe
Martini
Order management
ERP or fulfillment
Example Mapping
Stripe FieldCanonical FieldTarget Field
idpayment.externalIdpaymentReference
amountpayment.amountMinortotalMinorUnits
currencypayment.currencycurrencyCode
statuspayment.statuspaymentStatus
Martini Implementation

Martini receives and verifies the webhook, filters for the required event type, and retrieves the current Stripe object when needed. It maps minor-unit amounts with currency, applies fulfillment eligibility rules, persists the event ID before processing, and routes failures for retry without creating duplicate orders.

Martini features used:
  • REST API consumption
  • webhook-consuming service
  • data mapper
  • conditional routing
  • idempotency
  • error handling

Pattern 2

When to use this pattern

Use this pattern to keep recurring billing state aligned across Stripe, a CRM, billing database, or customer portal. Subscription and invoice events provide near-real-time changes, while scheduled reconciliation helps identify missed, delayed, or unsupported changes.

Data Flow
Stripe
Martini
Billing database
CRM or customer portal
Example Mapping
Stripe FieldCanonical FieldTarget Field
customerbilling.customerIdcustomerExternalId
subscriptionbilling.subscriptionIdsubscriptionReference
statusbilling.lifecycleStatusbillingStatus
amount_dueinvoice.amountDueMinoramountDueMinor
Martini Implementation

Martini routes subscription and invoice event types into separate business workflows, enriches records through Stripe API retrieval where appropriate, and applies create-or-update rules keyed by Stripe IDs. A scheduled workflow reads paginated resources or relevant Events API records, stores checkpoints, and retries only transient failures.

Martini features used:
  • webhook routing
  • scheduled workflows
  • cursor-based pagination
  • data mapper
  • database persistence
  • retry handling

Pattern 3

When to use this pattern

Use this pattern to synchronize Stripe Customers, Products, and Prices with a CRM, commerce catalog, or data warehouse. It is suited to initial loads and recurring synchronization where the target system requires a canonical schema rather than Stripe’s nested JSON structure.

Data Flow
Stripe
Martini
Canonical model
CRM or data warehouse
Example Mapping
Stripe FieldCanonical FieldTarget Field
idsource.objectIdstripeId
namecustomerOrProduct.namename
default_priceproduct.defaultPriceIddefaultPriceReference
unit_amountprice.amountMinorunitAmountMinor
Martini Implementation

Martini invokes the relevant list endpoints, follows has_more and starting_after cursors, transforms nested objects and optional fields, and writes repeatable upserts to the target. Persisted object IDs and synchronization timestamps prevent duplicates, while malformed records can be isolated for review without losing the batch checkpoint.

Martini features used:
  • REST API consumption
  • scheduler trigger
  • cursor persistence
  • JSON handling
  • data mapper
  • error queue and replay

Pattern 4

When to use this pattern

Use this pattern for Stripe Connect platform operations that need to synchronize connected Accounts, balances, payouts, charges, or application-fee information with an internal platform ledger. Account context must remain associated with every request and synchronized result.

Data Flow
Stripe Connect
Martini
Platform ledger
Operations reporting
Example Mapping
Stripe FieldCanonical FieldTarget Field
accountconnectedAccount.idaccountReference
amountledger.amountMinoramountMinorUnits
currencyledger.currencycurrencyCode
payout.statuspayout.statussettlementStatus
Martini Implementation

Martini receives Connect-related events or calls Stripe with the connected-account context, then maps account-scoped financial data into ledger and reporting services. It isolates credentials and account identifiers by environment, preserves the account reference, deduplicates events, and retries transient API failures without replaying completed ledger entries.

Martini features used:
  • REST API consumption
  • event routing
  • account-context handling
  • data mapper
  • secure secrets
  • monitoring and retry

How to build a Stripe integration in Martini

Objective

Configure the Stripe REST API credentials and any webhook signing or Connect account context without embedding secrets in services or source code.

Instructions in Martini

  • Store secret or restricted API keys in Martini deployment secrets.
  • Keep test-mode and live-mode credentials in separate environments.
  • Configure the webhook signing secret separately from the API key.
  • Apply connected-account context consistently when using Stripe Connect.

Objective

Select the event or schedule that matches the integration’s consistency and latency requirements.

Instructions in Martini

  • Expose a webhook-consuming service for selected Stripe event types.
  • Use a scheduler for initial loads and periodic reconciliation.
  • Use the Events API or recently changed objects to recover missed changes.
  • Persist event IDs or synchronization cursors for restartable processing.

Objective

Convert Stripe JSON objects into a canonical model that preserves identifiers, relationships, amounts, currencies, and optional fields.

Instructions in Martini

  • Map the required Stripe object and nested references.
  • Treat monetary values as integer minor units and carry the currency code.
  • Preserve Stripe object IDs and connected-account identifiers where applicable.
  • Handle nullable fields, metadata, and expandable references defensively.

Objective

Enforce payment, billing, fulfillment, reconciliation, and duplicate-processing rules before writing downstream data.

Instructions in Martini

  • Filter webhook events by supported event type.
  • Retrieve the current Stripe object when state freshness matters.
  • Use stable idempotency keys for retryable Stripe POST requests.
  • Deduplicate webhook deliveries by Stripe event ID.

Objective

Deliver the transformed result to enterprise APIs, databases, files, queues, or internal Martini services.

Instructions in Martini

  • Create or update target objects using stable Stripe identifiers.
  • Commit downstream actions only after the event is safely accepted.
  • Route validation failures separately from transient transport failures.
  • Store checkpoints after successful page or batch processing.

Objective

Make the integration observable and recoverable across rate limits, transient failures, duplicate events, and schema changes.

Instructions in Martini

  • Retry applicable 429 and 5xx responses with bounded exponential backoff.
  • Record Stripe request identifiers and relevant error payloads.
  • Monitor failed workflows, replay records, and reconciliation differences.
  • Test API-version changes and test-mode webhook scenarios before production rollout.

Common Stripe data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CustomersRepresent customers and store customer details, payment methods, and billing-related information.CRM, customer portal, ERP, data warehouseMartini maps Stripe Customer fields into a canonical customer model, preserves the Stripe customer ID, applies create-or-update rules, and synchronizes changes through paginated API reads, webhooks, or reconciliation.
PaymentIntentsTrack payment lifecycles, including authentication and confirmation states.Order management, fulfillment, ERP, payment operations databaseMartini consumes PaymentIntent API responses and selected payment events, checks the current status when necessary, carries amounts as integer minor units with currency, and prevents duplicate downstream actions with event IDs or idempotency keys.
ChargesRepresent payment charges created against a Customer or PaymentIntent.ERP, accounting, order management, reconciliation ledgerMartini retrieves and maps Charges with their Stripe IDs, amounts, currencies, statuses, and related object references. It can enrich records from the authoritative API before writing them to a target system.
SubscriptionsRepresent recurring billing arrangements and their lifecycle.CRM, billing database, customer portal, support platformMartini routes subscription-related webhook events, maps lifecycle states and customer references, and schedules reconciliation for missed or out-of-order changes. Optional fields and extensible states should be handled defensively.
InvoicesRepresent amounts owed, billing documents, and invoice payment status.ERP, accounting, billing database, customer communicationsMartini synchronizes Invoices through cursor-based list operations and selected invoice events, preserving invoice IDs, customer associations, statuses, amounts, and currency for downstream processing.
Products and PricesProducts describe what is sold, while Prices define amount, currency, and billing model.Commerce platform, catalog service, CRM, data warehouseMartini can read Products and Prices, normalize their relationship into a target catalog model, retain Stripe IDs, and use timestamps or persisted cursors to support repeatable scheduled synchronization.

Authentication and security considerations

API authentication

Stripe server-side REST requests generally use secret or restricted API keys. Store these credentials as Martini deployment secrets and keep test-mode and live-mode values separate. Publishable keys are intended for client-side use and should not be used for server-side administrative requests.

Webhook verification

Stripe webhook requests use an endpoint signing secret and signature header separate from API authentication. Martini webhook workflows should validate the signature against the unmodified request body before routing or processing an event.

Connect account context

Stripe Connect platforms may use OAuth and connected-account context. Preserve the connected account identifier and apply the appropriate account context consistently to API requests and event processing.

  • Use restricted keys where the required resource and operation scope permits.
  • Do not embed keys or signing secrets in workflow definitions or source code.
  • Isolate credentials, webhook endpoints, and data namespaces by environment.

Operational considerations for Stripe integrations

Reliability and rate limits

Handle HTTP 429 responses and transient 5xx failures with bounded exponential backoff. Retain Stripe request identifiers and relevant error details for troubleshooting, and avoid unnecessary polling or large object expansions.

Pagination and reconciliation

Stripe list responses commonly include data, has_more, and cursor-based navigation. Follow starting_after or the applicable cursor and persist checkpoints for restartable synchronization. Combine webhooks with scheduled reconciliation because webhook coverage is event-type specific.

Idempotency and ordering

Use stable Stripe idempotency keys for retryable POST requests. Webhook consumers should deduplicate by event ID, tolerate duplicate and out-of-order delivery, and retrieve the current object when the event payload may not represent the latest state.

Versions and data quality

Record the Stripe API version used by each integration and test upgrades before deployment. Treat nullable fields, expandable references, enum values, and webhook event types as changeable. Store monetary amounts as integer minor units with the associated currency.

Why use Martini instead of scripts or point-to-point integrations?

Beyond point-to-point scripts

Martini separates Stripe API access, webhook intake, transformation, business rules, and target delivery into maintainable services and workflows. This provides a clearer structure than embedding Stripe calls and downstream writes in one-off scripts.

Reliable orchestration

Martini supports event-driven and scheduled workflows, conditional routing, asynchronous execution, pagination, retry handling, and durable processing decisions. These capabilities help coordinate payment, billing, catalog, and reconciliation processes across enterprise systems.

Reusable integration services

Martini can consume Stripe’s REST API and expose usable internal services or API façades, while its data mapping and custom JVM-compatible logic support provider-specific transformations. Credentials remain managed through deployment configuration rather than application code.

  • Combine webhook processing with scheduled reconciliation.
  • Reuse canonical mappings across CRM, ERP, database, and reporting targets.
  • Monitor failures and support controlled replay instead of manually rerunning scripts.

Frequently asked questions

Does Martini have a native Stripe connector?

A native Martini Stripe connector is not documented in the supplied information. The integration is implemented by having Martini consume Stripe’s REST API and receive Stripe webhook events through Martini services and workflows.

Can Martini create Stripe PaymentIntents and Customers?

Yes. Martini can consume the corresponding Stripe REST endpoints, authenticate with a securely stored secret or restricted API key, map the request payload, and process the JSON response.

Can Stripe send payment events to Martini?

Yes. Stripe supports webhook delivery for selected event types. Martini can expose a webhook-consuming REST service, validate the Stripe signature, route events by type, and invoke downstream workflows.

Are Stripe webhooks guaranteed to arrive once and in order?

No. Stripe webhook deliveries can be retried, duplicated, or delivered out of order. Use the Stripe event ID for deduplication and retrieve the current object when ordering or state freshness matters.

How can Martini synchronize all Stripe Customers or Invoices?

Martini can use Stripe list endpoints with cursor-based pagination, following has_more and starting_after until the collection is complete. For ongoing synchronization, combine webhook processing with scheduled reconciliation and persist cursors or checkpoints.

Can Martini synchronize Stripe data with a database?

Yes, through Stripe’s REST API, webhooks, and Events API rather than direct access to Stripe’s internal database. Martini can normalize Customers, Invoices, payment, subscription, catalog, or ledger data and write it to a supported database.

How does Martini transform Stripe payloads?

Martini can map Stripe JSON into canonical models and target schemas, preserve object relationships and IDs, handle optional fields, and carry integer minor-unit amounts together with their currency codes.

Can Martini expose an API façade for Stripe?

Yes. Martini can expose a REST service that applies enterprise authentication, validation, transformation, and business rules before invoking Stripe’s REST API. This can provide a controlled internal interface without exposing Stripe secret keys to client applications.