PTC Offerwall Integration Guide for Publishers

A PTC offerwall can give visitors optional ads to view while giving a faucet or crypto site another source of revenue. The important part of an integration is the reward handoff: your server must know which user earned a reward and make sure the same completion is credited only once.

Disclosure: This guide is published by MoneyRain, which operates the MoneyRain Offerwall. The principles also apply when you evaluate other providers; always follow the provider's current integration documentation.

1. Set up a publisher site and a stable user ID

Create a publisher account and register the site or placement as the provider requires. Supply an HTTPS callback URL and configure the signing secret in a server-side environment or protected configuration file. Do not put the secret in JavaScript, a public repository, or a URL shown to users.

Pass a stable internal user identifier when opening the wall. It should let your backend find the right account without exposing an email address or other unnecessary personal information. Encode the identifier as required by the provider. A visitor changing a browser parameter must never be enough to create a reward.

2. Verify the callback on your server

A callback is a message from the network to your server reporting an event. Use HTTPS and verify every signature exactly as the provider specifies, including the correct bytes, fields, algorithm and secret. Use a timing-safe comparison. If the protocol includes a signed timestamp, enforce its documented tolerance and keep your server clock synchronized. Validate the event type, site, user, currency and amount before processing.

Only accept known users and expected events. Use fixed-point decimal or integer units for money, and reject malformed or negative amounts unless the provider explicitly documents a reversal event. Set reasonable request size limits and use prepared statements for database writes. Do not trust a browser redirect or a success screen as proof of a completed reward.

3. Make credits safe to repeat

Callbacks can arrive more than once, and an acknowledgement can be lost. Store the provider's stable event identifier with the relevant provider and site scope under a database uniqueness constraint. In one transaction, record the event and apply the balance change. If the same verified event arrives again, acknowledge the duplicate according to the provider's protocol without crediting the user twice.

Use the actual identifier and event types defined by your provider; do not invent an identifier from the amount or a timestamp. Keep the deduplication record for at least the documented retry and reconciliation period. A duplicate with conflicting details deserves investigation. Acknowledge a new event only after it is safely recorded or processed.

4. Test failures before launch

• Send a valid test event and confirm the intended account receives one credit.
• Send the same event twice, including concurrent deliveries, and confirm there is still only one credit.
• Try an invalid signature, an unknown user, a modified amount and an expired signed timestamp where supported.
• Simulate a database failure and a lost acknowledgement. Confirm your response, recovery procedure and provider retry behavior match the documentation.
• Reconcile a small set of completed events against your own ledger, and investigate gaps without blindly adding credits.

For more on signature verification and replay protection, see the OWASP webhook security guide. Once the integration works, use our PTC publisher revenue guide to measure its effect on your site.