Home How to How to Connect Paystack to Make.com: Step-by-Step Automation…

How to Connect Paystack to Make.com: Step-by-Step Automation Guide

🔗 Paystack × Make.com · Step-by-Step

How to Connect Paystack to Make.com: Step-by-Step Automation Guide

Stop manually checking your Paystack dashboard to see who’s paid. This guide shows exactly how to wire a Paystack webhook into Make.com — with signature verification, the real payload structure, and four ready-to-build automations: order logging, payment confirmations, team alerts, and stock checks.

~20 min
Setup time for the core webhook connection
$0
Make.com free tier (1,000 ops/month) is enough for most sellers
Real-time
Automation fires the moment a payment succeeds
No code
Entirely point-and-click in the Make.com interface

If you’re taking payments through Paystack, every successful transaction is an event your business should react to — log the order, confirm to the customer, alert your team, update stock. Without automation, that means logging into the Paystack dashboard repeatedly throughout the day and manually copying details into a spreadsheet or messaging the customer yourself.

Connecting Paystack to Make.com closes that gap. The moment a payment succeeds, Paystack sends a webhook — a small HTTP message — to a URL you control. Make.com receives that message and runs whatever automation you’ve built: adding a row to Google Sheets, sending a WhatsApp confirmation, posting to a Telegram group, or anything else Make.com can connect to (which is most things).


How the Connection Works

Paystack → Webhook → Make.com → Anywhere

One webhook, unlimited downstream automations

CUSTOMER Pays via Paystack checkout PAYSTACK Payment confirmed Fires “charge.success” webhook event POSTs JSON payload MAKE.COM Custom webhook receives payload → verifies signature → filters for charge.success → runs your scenario One scenario, many possible actions 📊 Google Sheets — log order 💬 WhatsApp/SMS — confirm 📣 Telegram/Slack — alert team Add more modules to the same scenario for inventory updates, accounting sync, and more

Two Ways to Connect — Which Should You Use?

Make.com offers two routes to Paystack data: the native Paystack app module (built-in connector) and a Custom Webhook that Paystack pushes data to directly. They solve slightly different problems, and most real automations end up using both.

ApproachHow it worksBest forReal-time?
Custom Webhook (recommended starting point)Paystack pushes a JSON payload to a Make.com webhook URL the instant an event happens (e.g. payment succeeds)Reacting to events — new payments, refunds, transfers✅ Yes — instant
Native Paystack App ModuleMake.com connects to your Paystack account via API key and can fetch data (list transactions, check status) or perform actions on a schedule or as part of a scenarioLooking up additional details, periodic checks, or actions like creating a transfer recipientDepends — usually scheduled or triggered by another step
The practical combination: Use the Custom Webhook as your scenario’s trigger (it fires the moment a payment succeeds, with no polling delay), and optionally add the native Paystack app module later in the same scenario if you need to fetch additional account details the webhook payload doesn’t include. For the vast majority of “when someone pays, do X” automations, the Custom Webhook alone is everything you need.

Step-by-Step: Setting Up the Webhook Connection

1
Step 1 · In Make.com
Create a New Scenario and Add a Custom Webhook Trigger
Log into Make.com → click Create a new scenario → search for “Webhooks” in the module picker → choose Custom webhook as your trigger module. Click Add to create a new webhook, give it a name like “Paystack — Payment Events,” and Make.com will generate a unique URL (it looks like https://hook.make.com/abc123...).
💡 Copy this URL immediately — you’ll paste it into Paystack in the next step. Make.com webhook URLs are always HTTPS, which Paystack requires.
2
Step 2 · In Paystack Dashboard
Add the Webhook URL to Paystack
In your Paystack dashboard, go to Settings → API Keys & Webhooks. Scroll to the Webhook URL field and paste the Make.com URL you copied in Step 1. Save your changes. From this point on, Paystack will send a notification to this URL every time a relevant event occurs on your account — successful charges, refunds, transfers, and more.
⚠️ Paystack has separate webhook URL fields for Test mode and Live mode. While building and testing your automation, set the webhook URL under Test mode and use Paystack’s test card numbers — switch to Live mode only once everything works correctly.
3
Step 3 · In Make.com
Trigger a Test Event and Capture the Payload
Back in Make.com, click Run once on your scenario — this puts the webhook in “listening” mode. Now trigger a real event: either make a small test payment through your Paystack checkout (in Test mode), or use Paystack’s dashboard option to resend a previous webhook event if available. Make.com will capture the incoming payload and display its structure — this is how Make.com learns the data fields available for use in later steps.
💡 If nothing arrives within a minute or two, double-check the webhook URL was saved correctly in Paystack and that you’re testing in the matching mode (Test webhook URL + test payment, or Live webhook URL + real payment).
4
Step 4 · In Make.com
Filter for the Event Type You Care About
Paystack’s webhook sends multiple event types to the same URL — charge.success, transfer.success, refund.processed, and others depending on your account activity. Add a Filter immediately after the webhook trigger: click the small filter icon on the connection line, set the condition to check the payload’s event field, and set it to equal charge.success (or whichever event your automation should react to). This stops the scenario from running for irrelevant events.
5
Step 5 · Security
Verify the Webhook Signature (Important)
Because your webhook URL is technically a public endpoint, anyone who discovers it could send fake payloads pretending to be Paystack. Paystack signs every genuine webhook request with a header called x-paystack-signature — a hash computed from the request body using your Paystack secret key. To verify: add an Iterator/Tools module that computes an HMAC SHA512 hash of the raw request body using your secret key, and compare it to the value in the x-paystack-signature header. If they don’t match, add a Filter to stop the scenario.
⚠️ This step is genuinely important if your automation triggers anything with financial or customer-facing consequences (sending payment confirmations, updating stock). For low-stakes internal notifications (a Telegram alert to yourself), some sellers skip this initially — but it should be added before relying on the automation for anything customer-facing.
6
Step 6 · In Make.com
Add Your Action Module(s)
After the filter (and signature check), add the module(s) for whatever should happen next — Google Sheets “Add a Row,” a WhatsApp/SMS API call, a Telegram “Send a Message,” or any combination. Map the fields from the Paystack payload (customer email, amount, reference number, etc.) into the corresponding fields of your action module by clicking into each field and selecting from the available payload data Make.com captured in Step 3.
💡 See the four ready-to-build recipes below for specific module combinations and what to map where.
7
Step 7 · Activate
Turn the Scenario On and Switch to Live Mode
Once a test payment flows through correctly and produces the expected result (a new row in your sheet, a WhatsApp message sent, etc.), toggle the scenario to ON (the switch in the top-right of the scenario editor) and update your Paystack webhook URL field from Test mode to Live mode using the same Make.com webhook URL. From this point, every real successful payment will trigger your automation automatically.

What’s Inside the Webhook Payload

When a charge succeeds, Paystack sends a JSON payload to your webhook URL. The structure looks roughly like this (simplified — actual payloads include additional fields):

Example charge.success payload
{
  "event": "charge.success",
  "data": {
    "id": 4099797291,
    "reference": "T123456789",
    "amount": 500000,  // amount in kobo/pesewas (÷100 for GHS/NGN)
    "currency": "GHS",
    "status": "success",
    "paid_at": "2026-06-12T14:32:00.000Z",
    "channel": "mobile_money",
    "customer": {
      "email": "customer@example.com",
      "first_name": "Ama",
      "last_name": "Owusu"
    }
  }
}

The fields you’ll use most often in automations: event (to filter on charge.success), data.reference (a unique transaction reference — useful as a lookup key in your order sheet), data.amount (remember to divide by 100 — Paystack amounts are in the smallest currency unit), data.channel (tells you whether the customer paid by card, bank transfer, or mobile money), and data.customer.email (or phone number, if collected, depending on your checkout setup).

On the signature header: The x-paystack-signature header contains an HMAC SHA512 hash of the raw request body, generated using your Paystack secret key. Verifying it confirms the payload genuinely came from Paystack and hasn’t been tampered with in transit. Your Paystack secret key is found in the same Settings → API Keys & Webhooks page where you added the webhook URL — never share this key or expose it in a public Make.com scenario template.

4 Ready-to-Build Automation Recipes

Each of these extends the same Custom Webhook trigger from the setup above — add the filter and signature check once, then branch into whichever (or however many) of these you need.

📊
Recipe 1: Auto-Log Every Order to Google Sheets
Replaces manual copy-paste from the Paystack dashboard

The most common starting automation — every successful payment becomes a new row in your order tracking sheet automatically, with no manual entry.

Webhook → Filter (event = charge.success) → Google Sheets: Add a Row

Map: data.reference → Order ID column, data.customer.email → Customer column, data.amount ÷ 100 → Amount column, data.paid_at → Date column, data.channel → Payment Method column. Set a default “Pending” value in your Order Status column for fulfilment tracking.

💬
Recipe 2: Send Order Confirmation via WhatsApp/SMS
Instant confirmation without you lifting a finger

The moment payment clears, the customer gets a confirmation message — improving trust and reducing “did my payment go through?” follow-up messages.

Webhook → Filter → HTTP module (Termii/Africa’s Talking API) → Send SMS/WhatsApp

Use Make.com’s HTTP — Make a request module to call your SMS/WhatsApp provider’s API (Termii, Africa’s Talking, or a WhatsApp Business API provider). Compose the message text using data.customer.first_name and data.reference: “Hi {{name}}, we’ve received your payment of GHS {{amount}}. Your order reference is {{reference}}. Thank you!”

📣
Recipe 3: Alert Your Team in Telegram or Slack
Know about every sale in real time without opening the dashboard

Useful for solo sellers and small teams — a notification appears the second money comes in, including the amount and what was purchased (if your checkout passes product info in metadata).

Webhook → Filter → Telegram: Send a Message (to a bot/group)

Create a Telegram bot (via @BotFor​ in Telegram, takes 2 minutes), add it to a private group, then use Make.com’s Telegram module to send a formatted message: “💰 New sale! GHS {{amount}} from {{customer.email}} — Ref: {{reference}} — via {{channel}}.” Slack works the same way using Make.com’s Slack module instead.

📦
Recipe 4: Decrement Stock and Flag Low Inventory
Requires product info to be passed via Paystack metadata

If your checkout passes which product was purchased in Paystack’s metadata field (custom data you attach when initiating the transaction), this recipe automatically reduces the stock count in your inventory sheet and sends an alert if stock drops below a threshold.

Webhook → Filter → Google Sheets: Search Row (by product name) → Update Row (decrement stock) → Filter (stock < 5) → Telegram: "Low stock alert"

This recipe is more advanced because it requires your checkout flow to send product identifiers in data.metadata — if you’re using a simple payment link without custom metadata, this field may be empty and this recipe won’t have the data it needs. Sellers using Zoho Inventory or similar dedicated tools may prefer to handle stock decrements within that platform instead, using Recipe 1 purely for the order log.


Which Recipe Should You Build First?

🎯 Get a Build Order Recommendation

One question — a suggested sequence based on your current setup

Suggested build order


Troubleshooting Common Issues

IssueLikely CauseFix
No data arrives in Make.comScenario wasn’t in “listening” mode when the test payment ran, or webhook URL wasn’t saved in PaystackClick “Run once” in Make.com before triggering the test payment. Re-check the webhook URL field in Paystack settings was saved (not just typed and navigated away from).
Scenario runs but nothing happens downstreamThe event filter is blocking everything, including the event you expectedTemporarily remove the filter, run a test, and inspect the actual event value in the payload — it may differ slightly from what you expected (check exact spelling/case).
Amount shows as 50000 instead of 500Paystack amounts are in kobo/pesewas (smallest currency unit), not in GHS/NGN directlyAdd a simple math operation in the field mapping: divide data.amount by 100 before writing it to your sheet or message.
Works in Test mode, nothing in Live modeThe Live mode webhook URL field in Paystack wasn’t updated, or you’re still using the test API keys for signature verificationConfirm both the Live webhook URL is set AND, if doing signature verification, that you’re using your Live secret key (not the test secret key) for the HMAC calculation.
Signature verification always failsThe HMAC is being computed on a modified/re-serialized version of the body rather than the exact raw bytes Paystack sentEnsure the signature check uses the raw request body string exactly as received — re-formatting or re-parsing the JSON before hashing will produce a different hash than Paystack’s.
Make.com free tier operations running outEach module execution within a scenario run counts as an operation — a scenario with many modules consumes multiple operations per paymentCombine steps where possible (e.g. one HTTP module instead of several), or upgrade to Make.com’s Core plan (~$9/month for 10,000 operations) once volume justifies it.

5 Mistakes to Avoid

❌ Building and testing directly in Live mode
Testing with real payments means real money moving for every test run, and any mistakes in the automation (sending the wrong message, logging incorrect amounts) happen to real customers and real records.
→ Fix: Always build and fully test using Paystack’s Test mode and test card numbers first. Only switch the webhook URL to Live mode once the scenario behaves correctly end to end.
❌ Forgetting the event filter entirely
Without a filter on the event field, your scenario runs for every webhook Paystack sends — including refunds, failed charges, and transfer events — potentially logging a “refund” as if it were a new sale, or sending a payment confirmation for a failed transaction.
→ Fix: Always add a filter immediately after the webhook trigger, checking event equals exactly the event type your automation is designed for (typically charge.success).
❌ Skipping signature verification on customer-facing automations
An automation that sends WhatsApp confirmations or updates customer-visible order status based on an unverified webhook could be triggered by anyone who discovers the webhook URL — sending fake confirmations or manipulating order records.
→ Fix: Implement the HMAC SHA512 signature check from Step 5 for any automation with customer-facing or financial consequences. For purely internal alerts (a private Telegram notification only you see), this is lower priority but still good practice.
❌ Not accounting for the amount being in kobo/pesewas
A sale of GHS 50 will show as 5000 in the raw payload. Logging or messaging this number without dividing by 100 makes every recorded amount appear 100× too large.
→ Fix: Always divide data.amount by 100 when mapping it into sheets, messages, or any downstream system. Double-check this with a real test transaction of a known amount.
❌ Treating this as “set and forget” with no monitoring
Automations can silently break — an API a downstream module depends on changes, a Google Sheet gets renamed or moved, or Make.com’s free tier operation limit is reached partway through a busy day, causing the scenario to pause.
→ Fix: Make.com sends email notifications when a scenario errors — make sure these go to an email you actually check. Periodically (weekly is reasonable) spot-check that recent orders are appearing correctly in your sheet/messages.

Frequently Asked Questions

Do I need a developer to set this up?

No — everything in this guide is point-and-click within Make.com’s visual interface and Paystack’s dashboard settings. The most technical step is signature verification (Step 5), which involves an HMAC calculation — Make.com has built-in functions for this, and template scenarios that include signature verification are widely shared in Make.com’s community, which can be adapted rather than built from scratch. If you’re not comfortable with Step 5 initially, recipes for internal-only notifications (Recipe 3) are reasonable to run without it while you get comfortable with the rest of the setup.

Will this work with Flutterwave instead of Paystack?

The same overall pattern applies — Flutterwave also supports webhooks that POST to a URL you provide, with its own signature verification mechanism (a secret hash you set in your Flutterwave dashboard, sent back in a verif-hash header for you to compare). The specific payload structure and field names differ from Paystack’s, so the field mappings in Steps 3 and 6 would need to be redone based on Flutterwave’s payload, but Make.com’s Custom Webhook trigger works identically as the entry point for either provider.

What happens if Make.com is down when a payment comes in?

Paystack retries webhook delivery if it doesn’t receive a successful response, so a brief outage on Make.com’s side typically doesn’t mean a permanently lost event — Paystack will attempt redelivery. That said, webhooks should be treated as a convenience layer for automation, not the sole record of a transaction — your Paystack dashboard remains the authoritative record of all payments regardless of whether downstream automations ran successfully, which is why periodic spot-checks (mentioned in the mistakes section) matter.

Can I trigger different automations for different payment channels (card vs Mobile Money)?

Yes — the payload includes a data.channel field (values like card, mobile_money, bank_transfer). Add an additional filter or a Router module (Make.com’s branching tool) after your main event filter to send card payments down one path and Mobile Money payments down another — useful if, for example, you want different confirmation message wording depending on how the customer paid.


Start With One Recipe, Then Expand

The temptation once this is working is to build everything at once. Don’t — get Recipe 1 (order logging) working end to end first, including the signature verification if your automation will touch customer-facing actions. Once that’s reliable, adding Recipes 2–4 to the same scenario is straightforward, since the trigger, filter, and security check are already in place. Each additional recipe is then just a few more modules branching off the same foundation.

More at OurInternetBusiness.com

Practical guides on automation, online business systems, and growing income from Ghana and across Africa. Visit OurInternetBusiness.com and bookmark it.