We integrate payment infrastructure using server-side API calls and cryptographically verified webhooks to keep transaction handling secure, decoupled, and compliant. The Technology department builds and tests these connections within your stack to ensure payment states reconcile accurately against client records and order management systems.
Merchant accounts and credential handover
You must hold your own merchant account with the chosen payment gateway (for example, Stripe, Mollie, or Adyen). Xylora Studios operates as an integrator; we do not sit in the financial flow, hold settlement balances, or accept custody of transaction receipts.
To begin integration, you must supply restricted developer credentials generated inside your gateway dashboard. Never send primary administrator logins or root account passwords. The required items are:
* A restricted API secret key with write permissions limited strictly to charges, payment intents, and customer records. * A publishable or public client-side key for frontend checkout rendering. * Access to configure or verify the webhook endpoint URL and signing secret.
If you require assistance generating restricted keys, request an access delegation walkthrough through Ask Xylo on this portal.
Technical integration sequence
Payment setup follows a four-stage process managed by the Technology department between Monday and Thursday (09:00–17:00 GMT):
1. Environment scaffolding: We install the gateway SDK or build native HTTP clients on your application backend. Sandbox keys are loaded into environment variables; no credentials are ever hard-coded in repositories. 2. Checkout workflow: We implement the client-side checkout flow. Whether using an embedded payment element, a hosted redirect, or custom form tokens, the sensitive cardholder data passes directly to the gateway’s PCI-DSS compliant vault, returning only a token or payment intent ID to your server. 3. Webhook endpoint deployment: We deploy an unauthenticated public HTTPS route dedicated to receiving asynchronous gateway events. 4. Sandbox verification: We simulate successful payments, 3D Secure challenges, soft declines, expired sessions, and disputes to confirm system handling before moving live.
Bespoke integration logic, complex tiered billing, or marketplace splits are scoped on bespoke quotes provided within 48 hours of receiving a complete architectural brief. Fixed configurations included in standard scope follow the options outlined on the packages page.
Webhook architecture and idempotency
Client-side payment confirmations (such as redirect success screens) are inherently untrusted; browsers can be closed early, scripts can be blocked, or network drops can interrupt the final redirect. All business logic—such as granting digital access, provisioning accounts, or triggering production pipelines—is executed exclusively via server-side webhooks.
Our webhook listeners enforce three technical requirements:
* Cryptographic signature validation: Every incoming request payload is validated against the gateway’s signing secret using an HMAC SHA-256 algorithm before the body is parsed. Payloads with missing or invalid signatures are rejected immediately with an HTTP 400 response. * Idempotent processing: Gateways deliver events on an 'at-least-once' basis, meaning network retries can deliver the exact same event multiple times. Our handlers log each processed event ID in an atomic database store. If an event ID has already been executed, the handler immediately returns an HTTP 200 OK without re-running fulfilment routines. * Fast acknowledgement: Handlers acknowledge receipts within two seconds. Heavy downstream tasks (such as invoice generation, transactional email dispatch, or inventory reservations) are placed onto background job queues rather than processed during the inbound request lifecycle.
Edge cases, failures, and reconciliations
During development, we build defensive controls for common transaction failure states:
* Webhook timeouts: If your primary application server experiences downtime, the gateway will back off and retry event delivery according to an exponential schedule over 24 to 72 hours. We configure monitoring alerts to flag persistent webhook delivery failures. * Partial captures and charge mismatches: The handler compares the captured amount and currency code returned by the gateway payload against the expected database order record. If a currency or value mismatch occurs, the order is locked into an internal review state to prevent incorrect order fulfilment. * Payment disputes and chargebacks: Webhook listeners are mapped to charge dispute events, automatically revoking platform permissions or notifying Operations & Client Services if an account enters an uncollected state.
Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site.
Implementation checklist
Before requesting go-live sign-off, verify the following configuration:
* Gateway account identity verification and bank payout details are fully completed and verified by the provider. * Restricted API keys and production webhook secrets are placed into your secure hosting environment variables. * SSL/TLS certificate is active and scoring an A-grade on the receiving webhook domain. * Test cards have successfully simulated approved payments, card declines, and 3D Secure authentication. * Event deduplication has been verified in sandbox logs to prevent double fulfilment. * Webhook failure alerts are routed to your administrative monitoring channel.