Monitor your checkout so a broken payment step can’t look like no demand

1. Call the payment API with the live key every day

This is the check that would have caught the six-day outage. Create an API flow in Vigil and paste the steps for your provider. Each step is a real request; assertions are checked against the response, and extract passes a value to the next step as {{name}}. Replace the placeholders with your own key and IDs. Run it every hour or once a day.

[
  {"name": "Paddle key works, price is active", "method": "GET",
   "url": "https://api.paddle.com/prices/pri_YOUR_PRICE_ID",
   "headers": {"Authorization": "Bearer YOUR_PADDLE_API_KEY"},
   "expect_status": "200",
   "assertions": "json data.status == active",
   "extract": {"product_id": "json:data.product_id"}},
  {"name": "Its product is active", "method": "GET",
   "url": "https://api.paddle.com/products/{{product_id}}",
   "headers": {"Authorization": "Bearer YOUR_PADDLE_API_KEY"},
   "expect_status": "200",
   "assertions": "json data.status == active"}
]

[
  {"name": "Stripe key works", "method": "GET",
   "url": "https://api.stripe.com/v1/balance",
   "headers": {"Authorization": "Bearer YOUR_STRIPE_KEY"},
   "expect_status": "200",
   "assertions": "json object == balance"},
  {"name": "Checkout price is active", "method": "GET",
   "url": "https://api.stripe.com/v1/prices/price_YOUR_PRICE_ID",
   "headers": {"Authorization": "Bearer YOUR_STRIPE_KEY"},
   "expect_status": "200",
   "assertions": "json active == true"}
]

[
  {"name": "Razorpay key works", "method": "GET",
   "url": "https://api.razorpay.com/v1/payments?count=1",
   "headers": {"Authorization": "Basic BASE64_OF_KEY_ID_COLON_KEY_SECRET"},
   "expect_status": "200",
   "assertions": "json entity == collection"}
]

printf '%s' 'rzp_live_YOUR_KEY_ID:YOUR_KEY_SECRET' | base64

Which key? Test the key your checkout code actually uses. A separate monitoring key proves nothing about the real one, because it will not expire on the same day. For Stripe you can create a restricted key with read access to Balance and Prices for monitoring, but then also calendar the real key's expiry (step 4).

Don't want the live key outside your server? Add a small route to your app that makes the same call with the key it already has, and point a plain API check at it with the assertion json payments == ok. The key never leaves your server, and the check tests the exact key and code path your checkout uses.

# Option B: keep the key on your server. A route that makes the same call your checkout makes:
@app.get("/healthz/payments")
def payments_health():
    r = httpx.get(f"https://api.paddle.com/prices/{PRICE_ID}",
                  headers={"Authorization": f"Bearer {settings.PADDLE_API_KEY}"}, timeout=10)
    ok = r.status_code == 200 and r.json()["data"]["status"] == "active"
    return JSONResponse({"payments": "ok" if ok else "failing"}, status_code=200 if ok else 503)

2. Ping a heartbeat from your payment webhook

The API check proves you can take money. A heartbeat proves you did. After your webhook handler has verified and processed a paid order, it pings a Vigil heartbeat URL. If no ping arrives within your normal gap between sales, you get an alert. It also catches a broken webhook: payments that succeed but never unlock anything.

import urllib.request

HEARTBEAT_URL = "https://puzaricloud.in/ping/<token>"


def ping_sale_heartbeat():
    """Call this after a paid-order webhook was verified and processed."""
    try:
        urllib.request.urlopen(HEARTBEAT_URL, timeout=5)
    except Exception:
        pass   # never let monitoring break the webhook itself


# Paddle:   event_type == "transaction.completed"
# Stripe:   event.type == "checkout.session.completed"
# Razorpay: event == "payment.captured"

// Node 18 and later: after the webhook is verified and the order is saved
fetch("https://puzaricloud.in/ping/<token>", { signal: AbortSignal.timeout(5000) }).catch(() => {});

Set the heartbeat period to the longest normal gap between sales. If you sell a few times a day, 24 hours with a grace of a few hours works. If sales are rarer, use 3 or 7 days, and lean on the daily API check for fast detection. An alert here does not always mean something broke; sometimes it is a slow week. But it is a slow week you now know about on day one, with the API check telling you whether the checkout still works.

3. Watch the pricing page for the buy button

Create a Keyword monitor on your pricing or checkout page with the rule disappears and the text of your buy button, for example Buy now, or the provider's script: cdn.paddle.com/paddle/v2/paddle.js, js.stripe.com or checkout.razorpay.com/v1/checkout.js. You get an alert when a deploy removes it.

A keyword monitor reads the HTML your server sends. If the button is drawn by JavaScript after the page loads, put the check on the script tag instead, or use a browser check, which runs the page in a real browser and can click the button.

4. Put the key's expiry date in your calendar

When you create or rotate a key, write its expiry date down where you will see it: a calendar event 14 days before, sent to an address you read. The daily API check catches the day it breaks; the calendar entry stops it from breaking at all. When you rotate, update every place the key lives (production, staging, the CI secret and the Vigil flow) and run the flow by hand once.

On Paddle you can also subscribe to the api_key.expiring webhook, which Paddle sends seven days before a key expires, and api_key.expired. Send them somewhere you read, not only to your app's log. (Paddle: API key expiration)

No monitoring tool? A cron job and Healthchecks.io

If you have a server with cron, you can get the most important check without any monitoring tool: call the API with the live key once a day and ping a free Healthchecks.io check only when it worked. If the key breaks, the ping stops and Healthchecks.io emails you.

# once a day at 09:00: call the provider with the live key, ping Healthchecks.io only if it worked
0 9 * * * curl -fsS -m 20 -o /dev/null -H "Authorization: Bearer $PADDLE_API_KEY" "https://api.paddle.com/prices/pri_YOUR_PRICE_ID" && curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-check-uuid>

# Stripe: same idea
0 9 * * * curl -fsS -m 20 -o /dev/null -u "$STRIPE_KEY:" https://api.stripe.com/v1/balance && curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-check-uuid>

# Razorpay: same idea
0 9 * * * curl -fsS -m 20 -o /dev/null -u "$RAZORPAY_KEY_ID:$RAZORPAY_KEY_SECRET" "https://api.razorpay.com/v1/payments?count=1" && curl -fsS -m 10 --retry 3 -o /dev/null https://hc-ping.com/<your-check-uuid>

curl -f treats a 401 or 404 as a failure, so the second curl only runs when the provider accepted the key. Vigil's heartbeat URLs use the same format, so you can point the same line at Vigil later.