Partner Gateway Integration

PlayCamp Partner Gateway relays authentication, webhook conversion, and payment synchronization between your game server and PlayCamp SDK API. This allows you to integrate with PlayCamp while maintaining your existing API specifications.

Partner Gateway integration requires prior setup by a PlayCamp technical engineer. Please discuss with your PlayCamp representative before starting. Authentication method, webhook payload format, and payment API specifications must be agreed upon in advance.

When to Use This Method

Your game server already has its own API specifications that differ from PlayCamp’s standard format
Your authentication method differs from PlayCamp’s standard (Bearer Token) — e.g., SHA256 custom signatures
You prefer Gateway-polled payment synchronization instead of directly sending payments to PlayCamp
You want to minimize changes to your existing systems while integrating PlayCamp

Full Flow

Development Tasks

#	Task	Owner	Description
1	Place entry point in game	Game Client	Boost icon/button
2	Generate auth data	Game Server	Create signature for Gateway authentication
3	Call Gateway URL	Game Client	Open browser with signature
4	Webhook receiver endpoint	Game Server	Receive converted events from Gateway
5	Provide payment query API	Game Server	API for Gateway to poll payment history

The specific specifications for tasks 2, 4, and 5 are finalized during prior consultation with the PlayCamp technical engineer.

Step 1: WebView Entry (via Gateway)

Instead of calling PlayCamp WebView directly, you go through the Partner Gateway URL. The Gateway verifies authentication and redirects to PlayCamp WebView.

Entry URL

GET https://{gateway-domain}/api/{partner}/sponsor?usn={userId}&camp_code={campaignId}&custom_data={signature}

Parameter	Required	Description
`usn`	Yes	Game user unique ID
`camp_code`	No	PlayCamp campaign ID
`custom_data`	Yes	Authentication signature data

Parameter names (usn, camp_code, custom_data) may vary per game. Actual parameter names are finalized during prior consultation with the PlayCamp technical engineer.

Authentication Method

Generate signature data on the game server and pass it to the client. Typically uses SHA256-based signature + timestamp expiry verification.

Signature generated using a pre-shared secret key (sharedKey)
Timestamp validity check prevents replay attacks

The specific signature generation method and parameter structure are provided during consultation with the PlayCamp technical engineer.

Response

HTTP	Description
302	Auth success → Redirect to PlayCamp WebView
401	Auth failure (signature mismatch, timestamp expired, etc.)

Step 2: Webhook Receiver (Gateway → Game Server)

When the user selects a creator in WebView, events flow from PlayCamp → Gateway → Game Server. The Gateway converts PlayCamp’s standard format into a format your game server can process.

Event Types

PlayCamp Event	Delivered to Game Server
`sponsor.created`	Boost registered (1 event)
`sponsor.ended`	Boost removed (1 event)
`sponsor.changed`	Boost removed + Boost registered (split into 2 events)

Game Server Receives (Example)

{
  "events": [
    {
      "custom_data": "100001|1700000000|a1b2c3d4...",
      "usn": 100001,
      "creator_usn": 17324966,
      "event": "sponsor.created",
      "timestamp": 1741588200
    }
  ]
}

The payload format is negotiated to match your game server’s existing specifications. The example above is for reference only — actual field names and format are finalized during prior consultation.

Game Server Response

Return HTTP 200 with a result on success.

{ "result": "OK" }

On failure responses, the Gateway automatically retries (up to 5 times with progressive intervals).

callbackId Usage

The custom_data passed during WebView entry is stored as callbackId in PlayCamp. The same value is included in webhook events, so your game server can match the original entry request with webhook events.

Step 3: Payment Sync (Gateway Polls)

Instead of your game server sending payments directly to PlayCamp, the Gateway periodically polls your game server’s payment API and bulk-registers them with PlayCamp. Provide an API on your game server that returns payment history by period, and the Gateway will periodically poll it to automatically register payments with PlayCamp.

Game server’s role: Provide a query API that returns payment history by date range
Gateway’s role: Automatically converts game server responses to PlayCamp Bulk Payment API format and sends them
Deduplication: Automatic deduplication on PlayCamp’s side based on transaction ID
Auto-retry: Progressive retry intervals on transfer failure

The payment query API endpoint, authentication method, and request/response format are finalized during consultation with the PlayCamp technical engineer. If your game server already has a payment query API, its existing specification can be used as-is.

Step 4: Settlement

Monthly settlement is processed based on payment data.

Revenue Close — Payment data aggregated at end of each month
Revenue Reconciliation — Match PlayCamp settlement data with your internal records
Settlement Payment — Payment after reconciliation confirmation
Creator Settlement — PlayCamp distributes revenue to creators

Details: Settlement

Security

Segment	Authentication
Game Client → Gateway	SHA256 signature + timestamp expiry verification
PlayCamp → Gateway (Webhook)	HMAC-SHA256 signature verification
Gateway → Game Server (Webhook)	Agreed upon in advance (game server’s own verification)
Gateway → Game Server (Payment API)	IP whitelist + SHA256 fingerprint
Secret key storage	AES-256-GCM encryption

Comparison with Direct WebView Integration

Aspect	Direct WebView	Partner Gateway
Authentication	PlayCamp standard (Bearer Token)	Can maintain game’s existing method
Webhook format	PlayCamp standard JSON	Converted to game server format
Payment registration	Game server calls API directly	Gateway polls and auto-syncs
Game server changes	Add PlayCamp API call logic	Only provide payment query API
Prior consultation	Not required (self-service via docs)	Required with PlayCamp technical engineer

Platform

For Developers

For Creators

Partner Gateway Integration

When to Use This Method

Full Flow

Development Tasks

Step 1: WebView Entry (via Gateway)

Entry URL

Authentication Method

Response

Step 2: Webhook Receiver (Gateway → Game Server)

Event Types

Game Server Receives (Example)

Game Server Response

callbackId Usage

Step 3: Payment Sync (Gateway Polls)

Step 4: Settlement

Security

Comparison with Direct WebView Integration

​When to Use This Method

​Full Flow

​Development Tasks

​Step 1: WebView Entry (via Gateway)

​Entry URL

​Authentication Method

​Response

​Step 2: Webhook Receiver (Gateway → Game Server)

​Event Types

​Game Server Receives (Example)

​Game Server Response

​callbackId Usage

​Step 3: Payment Sync (Gateway Polls)

​Step 4: Settlement

​Security

​Comparison with Direct WebView Integration

When to Use This Method

Full Flow

Development Tasks

Step 1: WebView Entry (via Gateway)

Entry URL

Authentication Method

Response

Step 2: Webhook Receiver (Gateway → Game Server)

Event Types

Game Server Receives (Example)

Game Server Response

callbackId Usage

Step 3: Payment Sync (Gateway Polls)

Step 4: Settlement

Security

Comparison with Direct WebView Integration