TikiPay Chatbot n8n Workflow Guide

1. Understand the integration boundary

A payment extension should not own your entire business workflow. TikiPay should create or identify a payment session, return a customer-facing payment experience, and give your backend enough information to verify the final payment state. Your platform should remain responsible for the local order, invoice, subscription, balance, course, hosting service or digital-delivery record.

Treat the browser return as a user-experience event and the backend verification response as the authoritative payment decision. This separation prevents a customer from forcing a paid screen by opening a success URL manually and makes the integration easier to audit when something goes wrong.

• Keep local order IDs and remote payment/session IDs mapped one-to-one.
• Never expose private API credentials in JavaScript, HTML, APK resources or public logs.
• Design fulfillment so the same verified payment cannot credit or deliver twice.

2. Production readiness before upload

Before installing TikiPay Chatbot n8n Workflow Guide, record the current platform version, PHP/runtime version, database version, active theme or template, caching plugins, reverse proxy or CDN behaviour and any existing payment customizations. A module can install successfully but still fail because a callback route is blocked, a cache serves stale configuration, or a security plugin rejects the request.

Create a recoverable backup before replacing files. For a production store, the safest process is to test the same package in staging or a cloned site first. Keep the old gateway files and configuration values available so you can roll back without interrupting checkout for long.

• Confirm HTTPS works without redirect loops.
• Confirm the application can make outbound HTTPS requests.
• Confirm the callback or webhook route is publicly reachable.
• Use test credentials during setup and live credentials only after the full test matrix passes.

3. Credentials and environment separation

Use separate configuration for test and live environments. A common failure is combining a production base URL with a sandbox key or a test URL with a live key. Store Brand API credentials in the protected setting provided by the platform, a server environment file, or a secret manager.

Do not paste credentials into screenshots, support tickets, public repositories or frontend source. If a credential is accidentally exposed, rotate it and update the integration immediately. Configuration should also include a clear gateway display name, success/cancel destinations and the server-side verification or webhook route.

• Trim accidental spaces when pasting keys.
• Do not hard-code a domain if the TikiPay integration supports environment-aware URLs.
• Document which brand/account owns each production key.
• Limit admin access to users who actually need gateway settings.

4. Installation sequence in a safe order

Install the package using the native extension flow of the target platform whenever possible. If the package requires manual upload, preserve its folder structure exactly. File names, namespaces, route locations and callback paths are often case-sensitive on Linux servers.

After activation, open the payment settings once before testing checkout. Save the configuration, clear application and browser cache, then verify that the TikiPay method appears only on the intended store, currency, product or invoice context.

• Download the TikiPay workflow JSON.
• Import the JSON into n8n.
• Inspect every node before activating it.
• Create or select the TikiPay HTTP credential/secret in n8n.
• Connect the incoming chatbot trigger to the payment-create nodes.
• Connect success/failure branches to customer messaging.
• Add backend verification before service delivery or access unlock.
• Test with a sample chat from start to verified completion.

5. Configuration field-by-field review

Do not treat the configuration screen as a copy-paste form. Each field affects a part of the payment lifecycle. The API credential authenticates server requests; the return URL controls where the customer goes; the webhook or callback allows asynchronous events; local status mapping determines whether an order stays pending, moves to processing or becomes completed.

If the platform has debug mode, use it only while testing and avoid logging secrets. If the integration offers a payment description, write a short customer-friendly message that explains the supported payment method and what the customer should do after paying.

• Set the customer-facing gateway title to TikiPay.
• Configure success, cancel and webhook/return URLs where supported.
• Keep API keys server-side; never expose them in browser JavaScript.
• Map COMPLETED, PENDING and failed/error states to safe local order states.
• Store your own order reference so each TikiPay invoice maps to exactly one local order.
• Make fulfillment idempotent so repeated callbacks cannot deliver twice.

6. Create-payment request design

When checkout starts, create the local order first and freeze the amount that is expected for that payment attempt. Send the customer identity fields required by the API, the exact amount, success/cancel URLs and an internal order reference or metadata value. This gives your server a stable record even if the customer closes the browser after payment.

Validate the API response before redirecting. A successful HTTP connection is not automatically a successful invoice creation. Check the response status, required payment URL and remote invoice/session identifier. Store that identifier with the local order so later verification can find the correct record.

• Never calculate the final payable amount only in the browser.
• Use server-side totals after discounts, taxes or wallet adjustments.
• Reject invalid or negative amounts before calling the API.
• Store the remote session or invoice reference before redirecting the customer.

7. Customer return flow

The success page should tell the customer that payment information is being verified, not blindly declare the order paid. The cancel page should keep the local order unpaid and offer a safe retry path. If the customer leaves without returning, webhook or later verification should still be able to reconcile the payment.

A good return page is fast and simple. It can poll your own backend for a short period or show a pending state while the server performs verification. The browser should never receive the private API key.

• Success redirect = customer experience signal.
• Server verification = payment decision.
• Cancel redirect must not delete the order immediately.
• Timeout should remain recoverable.

8. Backend verification and status mapping

After payment, the server should verify the invoice or transaction and compare it with the local order. Check the remote status, amount, invoice/session identifier, payment provider or reference where available, and whether the same transaction has already been consumed by another order.

Map COMPLETED to a one-time fulfillment action, PENDING to a waiting/recheck state, FAILED or ERROR to an unpaid state, and unknown/timeout to a recoverable review state. Keep this mapping centralized rather than scattering payment rules across controllers and templates.

• COMPLETED: verify amount/reference then fulfill once.
• PENDING: keep open and retry verification safely.
• FAILED/ERROR: do not deliver; allow customer retry if appropriate.
• Unknown/timeout: log, keep pending and re-query.

9. Webhook and callback handling

Webhook delivery can be delayed or repeated, so the handler must be idempotent. Load the local order by the stored remote reference, verify the current remote status, then apply the transition only if the local order has not already been fulfilled.

Return a quick HTTP response after safe processing. Expensive fulfilment such as generating a file, provisioning hosting or calling another API can be queued. Record only the information needed for audit and troubleshooting; do not dump secrets into logs.

• Verify before fulfillment even when a callback says success.
• Allow repeated callback delivery without repeated credit.
• Log timestamp, local order, remote reference and final state.
• Use HTTPS and protect internal callback routes from unrelated requests.

10. Testing matrix before live traffic

One successful test order is not enough. Run normal success, wrong amount, customer cancel, pending payment, duplicate callback, repeated browser refresh, delayed return, expired session, API timeout and invalid-credential scenarios. The goal is to prove that failure states stay safe, not only that the happy path works.

For billing, membership, SMM or wallet top-up integrations, verify that credit is applied exactly once. For ecommerce, confirm stock, email and fulfilment jobs are triggered only after the final paid state. For digital products, confirm a failed or pending customer cannot obtain the protected file.

• Test success with the smallest practical amount.
• Test wrong/partial amount if the payment method supports it.
• Test duplicate verification and duplicate callback.
• Test customer closing the browser after payment.
• Test network timeout between your server and TikiPay.
• Test rollback after temporarily disabling the extension.

11. Logs and observability

Payment support becomes much easier when the application records a small structured audit trail. Log the local order ID, remote invoice/session ID, verification timestamp, normalized status, provider/reference when available and the action taken by the application.

Avoid storing full secrets or unnecessary personal data. Build a simple operational view where support can distinguish pending, completed, failed and needs-review records. This reduces the temptation to approve payments manually from screenshots.

• Keep timestamps in a consistent timezone.
• Mask tokens and sensitive identifiers in logs.
• Make logs searchable by order and remote reference.
• Retain only what your operational and legal policy requires.

12. Security hardening

Use server-side validation for every amount and order state. Apply CSRF protection to admin forms, protect configuration pages with appropriate roles, and restrict file permissions for environment or configuration files. Disable directory listing and do not keep backup ZIP files inside a public web directory.

When using webhooks or callbacks, verify the payment again server-to-server before fulfillment. Rotate leaked credentials, use HTTPS, keep dependencies updated and review access logs if you see unusual create or verify traffic.

• No secret in source code repository.
• No secret in frontend JavaScript.
• No paid status based only on query-string values.
• No duplicate delivery without an idempotency guard.
• No automatic approval when expected amount does not match.

13. Performance and customer experience

The checkout button should disable after the first click while the server creates a payment session. This avoids accidental duplicate invoices. Use reasonable HTTP timeouts and show a useful retry message rather than leaving the customer on an endless spinner.

Do not run slow fulfilment jobs inside the browser request when they can be queued. The customer should receive a clear status quickly while the backend completes safe post-payment work.

• Prevent repeated create clicks.
• Use a short pending message while verification runs.
• Cache static assets, not payment status responses.
• Keep API calls server-side and time-bounded.

14. Upgrade, rollback and maintenance

Before updating TikiPay Chatbot n8n Workflow Guide, read the package notes, back up the current version and record settings. After updating, repeat at least one create/verify test and one failure-state test. Platform core updates can also affect payment hooks or route behaviour, so include payment testing in every release checklist.

If an update causes checkout errors, disable the new module or restore the previous package rather than editing production files blindly. Preserve database records and local order references during rollback so payments already in progress can still be reconciled.

• Keep the previous working package.
• Document configuration changes.
• Retest after platform, PHP/runtime or theme updates.
• Rotate keys only with a planned rollout so old in-flight requests are handled safely.

15. Production launch plan

Launch gradually. Enable TikiPay for a controlled set of users or a low-risk product first, watch logs and support requests, then expand. Keep another safe payment route available during the first production window if your business cannot tolerate checkout downtime.

Define who responds when an order remains pending, who can inspect verification records, who can rotate credentials and how customers are informed during an incident. A reliable payment integration is an operational process, not only a plugin installation.

• Run a final live low-value test.
• Confirm support contact and escalation owner.
• Confirm dashboard, callback and verify logs are visible.
• Confirm rollback path.
• Confirm customer-facing payment instructions are accurate.

17. Detailed troubleshooting reference

18. Extended FAQ