Skip to main content

The Payment Lifecycle

At the heart of the Sticitt platform is the Payment Object. Understanding how this object is created, processed, and verified is key to a secure integration.

Core Concepts​

  • The Payment Object: A server-side entity containing the amount, reference, and status of a transaction.
  • Payment ID: The unique identifier (GUID) returned by the API. This is the "key" you pass to the frontend.
  • Verification: The process of confirming a payment's status via the API or Webhooks.

This is the most secure and robust way to accept payments. It allows you to "own" the transaction lifecycle and receive real-time status updates.

High-Level Flow​

  1. Create: Your server creates a pending payment via the API.
  2. Handoff: You pass the paymentId to your frontend (Client).
  3. Process: The Client initializes the JS SDK (or opens a Payment Link) using that ID.
  4. Verify: Sticitt notifies your server via Webhook (or you poll the API) to confirm success.

Security Warning​

danger

Do not trust the Client! The JS SDK will emit events like onSuccess or onComplete. These are useful for updating your UI (e.g., showing a "Thank You" message), but you should never release goods or services based on these frontend events.

A malicious user can spoof frontend events. Always verify the payment status server-side using:

2. Static Payments (Fire & Forget)​

In specific scenarios where you have no backend server (e.g., a simple donation button on a static site), you can use "Static Payments."

In this flow, the Payment Object is created by the SDK / Link at the moment of interaction, rather than beforehand by your server.

Limitations​

  • ❌ No Webhooks: Since you didn't create the payment on your server, we have nowhere to send the webhook.

  • ❌ No Verification: You cannot query the API to check the status (since you don't have credentials on a static frontend).

  • ❌ Higher Risk: You must rely on the frontend success message, which is less secure.

Use Case Restriction

Static payments are not recommended for e-commerce or services where fulfillment verification is required. Use them only for simple, low-risk scenarios like donations.

For static payments, you can skip the "Create Payments" section and jump straight to the Javascript SDK.