Connect Make and Stripe: log test payment events without duplicate rows

Practice without creating real charges

The proposed workflow stores test-mode events such as payment_intent.succeeded in a ledger. It does not charge, refund or transfer money. Give the test connection and destination explicit names and keep them separate from production. The goal is to verify receipt and recording with authorized test data before considering a production integration.

Select a test connection and narrow event trigger

Make documents Stripe connections using an API key or OAuth. Check the environment and permissions required by the selected modules, and keep credentials in the connection rather than a spreadsheet or message. Subscribe only to the event types needed for the exercise. Verify the Stripe account and environment before expanding destinations or allowing routine execution.

Store the event and payment identifiers separately

The event ID identifies a particular event; the object ID identifies the payment or other resource it concerns. Store both so redelivery is distinguishable from a different event about the same payment. Suggested fields are event_id, event_type, object_id, created, livemode, amount and currency. Copying customer contact details is unnecessary for this ledger and increases the information exposed downstream.

Preserve currency units before formatting amounts

Confirm the selected amount field and the currency's minor-unit rules before producing a human-readable value. Dividing every currency by one hundred is incorrect. Preserve the raw integer and currency, with any formatted value in a separate column. A successful PaymentIntent event is not by itself a bank payout or a complete accounting revenue decision. Label this destination an event ledger.

Deduplicate deliveries without assuming order

Look for an existing event_id and avoid creating a second row for its redelivery. Search followed by create remains vulnerable to concurrent arrivals unless intake is serialized or the destination enforces uniqueness. Stripe does not guarantee delivery order. If you also maintain current payment state, retrieve the current object where necessary and keep that state projection separate from the immutable event history.

Reconcile the Stripe event with the stored row

Note the ID of a test event and compare it with Make's execution history and the destination row. Try redelivering that event, delivering a different event and denying destination writes. Successful webhook delivery is not evidence that a spreadsheet write completed. Define a separate completion check against the stored event identifier rather than relying only on the sender's delivery status.

Recover deliberately and treat production as a new rollout

If the row exists while the scenario reports failure, inspect which later action failed before rerunning. Search the event ID and resume unfinished work. Moving to production requires a fresh review of the account, event subscriptions, credentials, destinations and responsible operator; it is more than replacing a test key. Estimate receipt, lookup, storage and retries separately. The guide supplies proposed acceptance checks, not live payment results or measured credit use.

• Connect a website backend to a Make custom webhook
• Prevent duplicate writes in Make with stable keys and recovery states
• Handle Make errors: execution history, incomplete runs and safe retries