Use unique credentials
Use a strong unique password and enable additional account protections offered by the platform. Do not reuse credentials from your storefront, hosting panel or email account.
Paxlivo is built as non-custodial payment infrastructure. The platform coordinates crypto invoices and payment status, while wallet keys and recovery material should remain with the merchant.
A merchant can configure a store to receive payments without giving Paxlivo the seed phrase or private key used to recover or sign from the merchant wallet. Paxlivo staff should never ask you to send those secrets by email, chat or a support ticket.
If anyone claiming to represent Paxlivo asks for a seed phrase, private key or wallet backup, stop the conversation and contact Paxlivo through the official support details published on this website.
Never share a seed phrase, private key, hardware-wallet recovery backup or unrestricted administrator API credential with Paxlivo support.
A non-custodial gateway reduces custody exposure, but account compromise can still damage merchant operations. Secure your Paxlivo login, email account, API credentials and integration endpoints.
Use a strong unique password and enable additional account protections offered by the platform. Do not reuse credentials from your storefront, hosting panel or email account.
Create integration credentials with only the permissions required by the application and rotate them if they are accidentally exposed.
Password reset and account notifications depend on your email account. Protect it with strong authentication and keep recovery methods current.
Paxlivo cannot recreate a lost seed phrase or reverse an on-chain transaction after a merchant sends funds to the wrong destination. Maintain tested backups of wallet recovery information outside Paxlivo and follow the security practices recommended by your wallet provider.
Before changing a store wallet or payment method, verify the configuration with a low-value transaction and confirm that you can independently access the receiving wallet.
Payment detection does not make the underlying network instant or reversible. Confirmation time, transaction fees and chain conditions can change independently of Paxlivo. Merchants should choose fulfillment thresholds appropriate to the value and risk of each order.
For tokens such as USDT, the selected blockchain is part of the payment method. A customer should only send the token using the network shown on the invoice.
Order systems should verify invoice state through authenticated server-side integration or validated webhook events. Browser-side success pages are useful for customer experience, but they are not a substitute for a trusted payment status check.
Verify that payment events came from the expected Paxlivo endpoint before using them to change an order or account balance.
API keys and webhook secrets should not appear in front-end JavaScript, public repositories, screenshots or customer-facing error messages.
Retain invoice IDs, event timestamps and application logs needed to diagnose payment-state problems without logging seed phrases or private keys.
Send a low-value test payment and verify independent access to the wallet before advertising the payment method to customers.
Follow your wallet provider's backup guidance. Do not store the only copy of a recovery phrase inside Paxlivo or in a support conversation.
Create an invoice, make a low-value payment, confirm the expected payment state and verify that your application performs the fulfillment action exactly once.
Decide who can approve refunds, how the destination address is verified and which wallet is used to send the return transaction.
Include the store or invoice identifier when relevant, but never include wallet seed phrases, private keys or passwords.