How to Automate Website Screenshots from a Razorpay Payment Webhook with Make

Use Make’s Razorpay Watch Payment Captured instant trigger, then send an HTTPS request from Make’s HTTP module to a screenshot API. Store or forward the returned image or image URL, and make downstream work idempotent so retries do not create duplicate records. Make describes its trigger as firing when a payment is successfully captured. Make’s Razorpay integration and HTTP module documentation cover the relevant building blocks.

This guide assumes a payment should cause a screenshot of a page associated with that order—for example, a confirmation page or an approved product page. A payment webhook does not itself identify a safe page to visit. Select the target from a trusted allowlist or trusted order metadata. Never pass an arbitrary URL supplied by an untrusted customer into a screenshot service.

1. Choose the trigger and page to capture

Recommended: Make’s Razorpay trigger

Create a Make scenario and select Razorpay’s Watch Payment Captured instant trigger. Connect your Razorpay account using Make’s connection flow, then select the trigger settings available in your account. This route avoids building a separate webhook receiver when Make’s built-in integration provides the event information you need.

Choose the captured event when the screenshot should happen only after successful capture. Do not infer capture from an earlier authorization event: Razorpay notes that event payloads are snapshots, so a payment may have become captured by the time an authorization event is sent while that event’s payload still reflects authorization-time details. See Razorpay’s webhook documentation and payment state documentation.

Alternative: Razorpay webhook to a Make Custom webhook

In Make, add Webhooks > Custom webhook, create a webhook, and copy its generated HTTPS URL into Razorpay’s webhook configuration for the captured-payment event. Make’s custom webhook module can trigger a scenario from an external service; its webhook guide describes the queue and processing behavior. See Make’s Webhooks documentation and webhook processing details.

Security gate: Razorpay requires an HMAC-SHA256 signature calculated over the raw request body using the webhook secret. Its instructions caution against parsing or casting the body before computing the signature. The reviewed documentation does not establish that every Make-only configuration exposes that raw body and supports the required verification. Before sending production events directly to Make, confirm the exact setup can perform this check. If it cannot, place a small HTTPS verification endpoint in front: verify the signature against the untouched raw bytes, reject invalid requests, and pass only verified event data to Make. This is an implementation safeguard based on Razorpay’s documented requirement, not a claim about a tested Make configuration. Razorpay: validate webhook signatures.

Pick a trusted capture target

Map the payment or order identifier to a page your workflow is allowed to capture. Prefer a fixed mapping such as an approved page for a known product or a URL stored in trusted order metadata. Validate the hostname against an allowlist before making the screenshot request. Avoid URLs supplied directly in notes, custom checkout fields, or other user-controlled values unless your verification logic constrains them.

Also decide what the captured page should show. A public page is usually straightforward. A customer-specific page may contain personal or payment information; do not put secrets in a URL, and do not store or forward the resulting image to a destination with broader access than intended.

2. Build the Make scenario

1. Add the trigger. Use Razorpay’s Watch Payment Captured, or use a Custom webhook if Razorpay will call Make directly and you have handled the signature-verification question above.
2. Run a test event. Capture a test payment or send a non-production webhook. Inspect the fields Make receives. Identify the event ID, payment ID, order ID, amount/currency if needed, and any trusted metadata that selects the capture target.
3. Validate and deduplicate. Reject events without the expected captured status or a recognized order. Record processed event IDs in a durable store or database and stop if the event ID is already recorded. Use the Razorpay event ID header, x-razorpay-event-id, when handling direct webhook requests; with the built-in trigger, use the event identifier exposed by that module if available.
4. Resolve the capture URL. Use a controlled mapping or validated trusted metadata. Apply an allowlist to permitted schemes and hostnames. Do not let an event choose arbitrary internal or private network addresses.
5. Call the screenshot API. Add Make’s HTTP Make a request module. Configure an HTTPS request and map the resolved URL into the screenshot API’s URL parameter. Keep credentials in a protected connection or secret field, not in a publicly accessible document or page.
6. Handle the response. A synchronous API call can return image bytes directly; alternatively request a JSON result containing an image URL if the provider supports it. Map the response to your chosen destination, such as cloud storage or an internal order record. The storage integration and retention policy are choices for your workflow.
7. Record completion. Save the event ID, payment/order reference, capture target, result location, and processing status. This makes support and retry behavior understandable.
8. Add an error route. Route HTTP errors, timeouts, invalid responses, and destination failures to a retry or review path. Do not mark the event fully processed until the screenshot is safely stored or handed off.

Example scenario shape

Razorpay: Watch Payment Captured
  → Filter: expected captured event and recognized order
  → Data store: look up Razorpay event ID
  → Filter: continue only if not already processed
  → Resolve URL from trusted mapping / verified metadata
  → HTTP: Make a request to screenshot API
  → Storage or order system: save image or result URL
  → Data store: mark event complete
  → Error handler: log, retry safely, or notify an operator

In Make, filters can stop a bundle from proceeding when a condition fails. For an idempotency record, ensure the lookup and insert are safe under concurrent executions; a separate “check, then write” can race if two duplicate deliveries run at once. Use a unique event-ID constraint or serialize the relevant work where your storage design supports it.

3. Configure synchronous or asynchronous screenshot delivery

Synchronous request

A synchronous capture is the simplest flow: Make calls the screenshot endpoint and waits for the image or response. It keeps the scenario’s data path easy to follow, but a slow page or large image can consume execution time and make the scenario wait. Set a suitable HTTP timeout and decide what your error route does if the capture does not finish.

Asynchronous request and callback

For a long-running render or a workflow that stores the result in object storage, use a screenshot API’s asynchronous option if available. The initial call returns before the final image is ready; the service later calls a webhook with the result. Configure a second Make Custom webhook to receive that callback, then validate its signature when the provider offers signing, associate it with the original event, and store the result.

For ScreenshotOne specifically, its documentation describes async=true, response_type=json, webhook_url, and storage_return_location=true for an asynchronous result callback and stored-file location. Its callback uses X-ScreenshotOne-Signature with HMAC-SHA256 validation. Keep the Razorpay webhook secret and screenshot-provider signing secret separate. See ScreenshotOne async and webhook documentation.

Do not assume the initial accepted response means the screenshot succeeded. Track the job through its callback, account for callback failures, and make callback processing idempotent too. A callback can be retried or delivered more than once, so use a job or external identifier to connect it to the payment event.

4. Webhook reliability and security

• Verify authenticity. For direct Razorpay webhooks, calculate HMAC-SHA256 over the raw body with the configured webhook secret and compare securely with the received signature. Reject failures before triggering consequential work. Razorpay’s verification instructions.
• Deduplicate. Razorpay documents x-razorpay-event-id for identifying duplicate events. Persist processed IDs and make image storage, notifications, and record creation idempotent.
• Expect retries and out-of-order delivery. Razorpay retries failed deliveries with exponential backoff for 24 hours after event creation and cautions that events may not arrive in order. Use the event’s meaning and payment state instead of assuming arrival order. Razorpay Webhooks Best Practices.
• Account for Make’s queue. Make queues webhook requests that are not processed immediately. Instant webhook scenarios normally process in parallel; enable ordered processing only if sequential handling is needed and acceptable for throughput. Inspect queue and execution history when a request appears delayed. Make webhook processing.
• Keep secrets private. Use HTTPS. Do not expose Razorpay secrets, screenshot API keys, or webhook URLs with embedded credentials in a public page or client-side code. Restrict access to Make scenario logs and stored screenshots because event payloads and images can contain sensitive information.
• Control URL destinations. Allow only expected public hosts and schemes. Reject private IP ranges, localhost, unexpected ports, and redirect destinations outside your policy. This reduces the risk of turning a payment event into a request against an unintended system.

5. Troubleshooting

Symptom	Likely cause	Fix
No scenario execution	The wrong event was selected, the connection is not active, or a Custom webhook URL/event configuration is incorrect.	Confirm the captured-payment trigger, connection, and event subscription. Send a non-production event and inspect Make’s webhook logs.
Signature validation fails	The body was parsed or transformed before hashing, the wrong secret is configured, or the wrong signature header was read.	Verify the exact raw request bytes with the matching Razorpay webhook secret. If Make cannot expose raw bytes in the chosen route, verify in a small endpoint before forwarding.
The screenshot runs for an authorization event	The workflow treats an earlier authorization notification as proof of capture.	Trigger on successful capture or verify the current payment state before capture. Event payloads reflect the state at event time.
Two screenshots or records appear for one payment	Razorpay retried an event, or concurrent runs passed a non-atomic duplicate check.	Use the event ID as a unique idempotency key, make writes idempotent, and use an atomic uniqueness check or serialization.
Make receives the event but the scenario is delayed	Requests are queued, the scenario is busy, or ordered processing is enabled.	Inspect the webhook queue and running executions. Adjust scheduling or concurrency with awareness of ordering and downstream limits.
Screenshot API returns an error or no image	The target URL is malformed, blocked, unavailable, or the screenshot request timed out.	Check the encoded URL and API response. Retry transient failures with bounded backoff; route persistent failures for review. Do not retry an invalid or disallowed target unchanged.
Make rejects the webhook with a queue or rate error	The webhook queue is full or a rate limit is reached.	Review Make’s queue and processing schedule, reduce unnecessary incoming events, and ensure the scenario drains work promptly.
Async callback arrives but cannot be matched	The callback lacks a stable correlation value or the initial job was not recorded.	Attach a supported external identifier or persist the provider job reference before acknowledging the original event. Make callback handling idempotent.
Image URL stops working later	The provider’s returned URL is temporary rather than a durable archive.	Copy the image to storage you control or configure supported object storage, and record that durable location.

6. Performance, reliability, and cost

Scenario time: synchronous capture keeps the workflow simple but makes it wait for rendering and transfer. Async capture moves the wait to a callback and can be preferable when the workflow has other time-sensitive steps. Measure the actual page and flow in your account; the cited documentation provides no benchmark for this specific scenario.

Retries: retry only transient failures, use bounded backoff, and keep every side effect idempotent. Avoid retry storms when a target is consistently down or rejects automated access. Store enough status to distinguish “event received,” “capture requested,” “capture complete,” and “needs review.”

Capture cost: total usage depends on your chosen screenshot provider, Make plan/operations, storage, and how often the same event or page is captured. Deduplicate before calling the screenshot API; consider caching only when a fresh image is not required for each payment. Budget for failure handling and any storage/egress charges in the selected destination. No sourced per-run price or timing figure is available for this workflow.

Data retention: define who can access screenshots, how long they are retained, and whether the page can expose customer information. Use a private destination for sensitive captures and avoid placing credentials or payment data into URLs.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. From Make’s HTTP module, send the captured page URL and your API key to the screenshot endpoint:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

For Make, configure an HTTPS GET to https://api.screenshotneo.com/v1/shot with query parameters access_key and the mapped, validated url. Use the returned file as the image output in the next module. See the ScreenshotNeo API documentation.

Equivalent requests for Python and Node.js:

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await require('node:fs/promises').writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

• Cookie/consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
• Bot checks/CAPTCHAs, blank pages, failed loads, timeouts, and cache hits are never billed. Responses identify the page verdict and billing status in headers.
• An MCP server lets AI agents use screenshot, page-info, and PDF-capture tools.
• The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Sign up for ScreenshotNeo’s free plan and connect the endpoint to your Make scenario.

FAQ

Should the trigger be payment authorized or payment captured?

Use captured when the workflow should run only after successful capture. Authorization and capture are distinct payment states.

Can I use a customer-provided URL?

Only after validating it against a strict allowlist and rejecting destinations your workflow must not access. Prefer a trusted URL mapping.

Does a 200 response from a Make webhook prove the screenshot succeeded?

No. It can mean the event was accepted or queued. Track the later scenario result, and for asynchronous capture wait for and validate the provider callback.

Can I capture every payment?

The scenario can process each eligible captured event, subject to your Make, screenshot, and storage plan limits. Deduplicate deliveries so retries do not create duplicate captures.

Where should I keep the final image?

Use a destination with access controls and retention that fit the information shown in the page. A temporary provider URL may not be suitable as a permanent record.