Frequently asked questions
Find the maintained DEUNA guide for common questions about Admin, APIs, checkout, SDKs, plugins, testing, and webhooks.
On this page
These answers point to the current source of truth instead of duplicating configuration or API contracts that can change. If a page does not document a capability, treat it as unconfirmed and ask your DEUNA Technical Account Manager (TAM) before building against it.
Admin#
How do I get access to DEUNA Admin?
An authorized operator for your organization must invite you and assign the role needed for your task. Start with Manage users and roles, then follow Two-factor authentication if your account or organization requires it. API credentials do not create an Admin session.
Where do I configure a processor or payment method?
Open Connections in Admin and follow the guide for that provider. Credentials and availability are account- and environment-specific. Use Connections to understand the workflow and the provider catalog to confirm the published capability before configuring it.
Can I customize the checkout appearance?
Yes, within the controls supported by your checkout experience. Use Theme and shared controls for DEUNA theme configuration and the integration-specific customization page when a plugin or SDK adds its own constraints. Keep contrast, focus visibility, and mobile layouts usable after every change.
API integration#
Can I integrate directly through the API?
Yes. Run the API quickstart from a trusted backend, then use the endpoint catalog for the exact public request and response contract. Never place a private API key in a browser or mobile application.
Which credential should I use?
The answer depends on where the request runs and whose authority it needs. A client-side SDK uses the documented public application context; trusted server-to-server operations use a private API key; supported signed-in customer flows can additionally use a customer Bearer token. The decision table and header examples are in Authentication and API keys.
How do I test without affecting production?
Use sandbox credentials and the sandbox base URL documented in Integration essentials. Keep sandbox and production keys, webhooks, provider accounts, and merchant configuration separate. Validate both successful and failed flows before requesting production enablement.
Where are response and error codes documented?
The Errors and recovery reference explains public status codes and safe recovery. A specific endpoint's reference remains authoritative for its request, response, audience, and authorization requirements.
Checkout, SDKs, and plugins#
Which checkout integration should I choose?
Choose based on the user experience you need to own, the platform where it runs, and the trust boundary for payment data. Web Checkout compares the primary web path, while the SDK overview maps Web, iOS, Android, and React Native responsibilities.
Where are the SDK methods and callbacks?
Start in the SDK overview, select your platform, and use the shared event and response references where applicable. Do not assume that similarly named capabilities use identical methods on every platform.
Which payment methods can I show?
Payment-method availability depends on country, currency, channel, provider connection, and account configuration. Filter the generated provider catalog, then follow the chosen provider or payment-method guide. Do not infer availability from a screenshot or another merchant's checkout.
Can I integrate through a commerce plugin?
Use Plugins to see maintained commerce-platform integrations. For VTEX, start with the VTEX overview, complete the installation and configuration guides, and run a sandbox purchase before production rollout.
How do coupons, tax, shipping, or tips affect checkout?
These can use merchant-specific synchronous callbacks when that behavior is configured for your account. The dynamic checkout webhook guide explains the execution boundary, request and response mapping, validation, and failure handling. Do not invent a callback event or mutable field that has not been certified for your merchant.
Webhooks and payment results#
Do I need a webhook?
Use status webhooks when your backend must react to asynchronous payment changes without relying on the browser, a redirect, or an SDK callback. Some payment methods reach their final state after the customer leaves checkout. Implement the signed notification flow and reconcile the authoritative order state before fulfillment or another irreversible action.
What if a webhook is delayed, duplicated, or arrives out of order?
Verify the signature, durably accept the notification, deduplicate it, and prevent an older event from moving your local record backward. Delivery is not proof of exactly-once or lifecycle-order semantics. Follow Acknowledge and reconcile and use a separate reconciliation process for unresolved payments.
Is an SDK callback or browser redirect proof of payment?
No. Client-side completion is useful for the customer experience, but your backend should use the documented server-side result and asynchronous status flow before fulfillment. Keep UI state, payment state, and settlement state as separate concerns.
Documentation and AI tools#
Can an AI coding agent search these docs?
Yes. Connect a compatible client to the read-only DEUNA Docs MCP server. It searches the same public documentation, endpoint inventory, and provider catalog published by this site and does not require or accept your DEUNA credentials.
A capability is not documented. Should I assume it works?
No. Confirm it with your DEUNA TAM or the owner of the applicable public contract. Include the environment, product, provider, intended operation, and the public page you checked, but redact API keys, tokens, card data, private keys, and customer data.