Merchant & operations
Configure payment providers
Set up payment extensions, protect credentials, test hosted checkout, and understand provider-specific limits.
On this page
Start with a provider sandbox
Payment providers are optional Extensions, not interchangeable guarantees. Agovena's current support documentation does not claim live production verification for these adapters. Validate your account, currency, payment methods, webhook flow, and refund requirements before accepting real payments.
Open Admin → Extensions, install and enable the chosen provider, then open its settings. Settings require the extension to be enabled. Secret fields are not redisplayed; a blank secret field on a later save preserves the configured secret. Re-entering a secret can require recent-password confirmation. See extension settings behavior.
Do not place raw card details, API keys, webhook secrets, or authorization headers in product fields, order notes, logs, or support requests. Store credentials only in the supported private settings or protected environment.
Provider-specific setup
| Provider | Merchant configuration and boundary |
|---|---|
| Mollie | Start with a test API key. Configure /webhooks/payments/mollie. Available methods are methods within this extension, not separate packages. |
| Stripe | Configure a test secret key and the webhook signing secret for /webhooks/payments/stripe. Uses hosted Stripe Checkout. |
| PayPal | Configure client ID, client secret, webhook ID, and sandbox mode. Storefront checkout uses PayPal's official JS SDK popup overlay; API clients retain the direct approval redirect. One-time and automatic checkout use Orders v2. Automatic checkout stores a PayPal Vault authorization on successful capture; Core performs later renewal orders with vault_id and stored_credential. Supports verified approval capture, full and partial capture refunds, Vault authorization revocation and reconciliation at /webhooks/payments/paypal. |
| Paddle | Set the Billing API key, Paddle.js client token, webhook secret and sandbox mode. Use the public /paddle/checkout launcher as Paddle's Default payment link. Creates inline prices from the order total, supports full and partial refunds, and uses Paddle-managed subscriptions for automatic renewal. Agovena previews and filters the selected Paddle payment method by transaction context; /webhooks/payments/paddle is required and cannot be disabled. |
| Tebex | Configure project_id, secret_key and webhook_secret. No product-to-package mapping is required: Agovena sends custom item names, prices, quantities and metadata to Tebex's /checkout endpoint. The official Tebex icon-mark is used for the single tebex:tebex method. The provider-hosted checkout is opened by redirect. Uses /webhooks/payments/tebex, including signed validation-webhook handling. Basket reconciliation resolves the real tbx- transaction before refunds. Full refunds and provider-managed recurring lifecycle are supported within the extension's single-subscription-item, no-trial and period-end cancellation boundaries; partial refunds are not supported. The Checkout API has no separate global payment-method discovery endpoint. |
Tebex is production-ready for this documented integration scope. Tebex account approval, provider configuration and operational Sandbox/live verification remain merchant responsibilities and are not required for package installation.
Prefix webhook paths with your real public HTTPS store origin. Do not add a fabricated Mollie HMAC secret: the Mollie implementation fetches the referenced payment through its authenticated API. Stripe and other signed providers use their own verification mechanisms. A successful HTTP response to a manually typed URL is not a valid provider webhook test.
Source references: Mollie setup, Stripe setup, PayPal settings, Paddle gateway, and Tebex gateway.
Check connection without charging
After enabling and configuring the provider:
php artisan agovena:verify-providers
For Mollie test credentials specifically:
php artisan agovena:verify-providers mollie --sandbox
The command checks exposed extension health callbacks without creating payments, shipments, or servers. The sandbox credential guard specifically refuses Mollie live-prefixed keys; do not assume the flag forces every other provider into test mode.
Read the result, not just the exit code: no enabled health callbacks can result in a warning and successful exit. A connection check is not proof of payment, refund, or recurring authorization.
Test the complete customer flow
Use a real provider test account and a restricted store. Verify:
- Payment methods available to this account appear for the intended currency and order.
- Hosted checkout succeeds in sandbox and the resulting payment, order, and invoice agree.
- Returning before the webhook does not prematurely mark the order paid.
- A delayed or repeated webhook does not duplicate fulfillment.
- Cancellation, expiry, and failed payment remain unpaid and provide an appropriate retry path.
- Supported full and partial refunds are reflected in both provider and Agovena records.
- Subscriptions and renewals work separately. PayPal stores a reusable Vault authorization during the first Orders v2 payment; Core performs later renewal orders. Paddle owns its provider-managed subscription flow. Verify each provider's renewal and cancellation behavior in addition to the initial payment.
Keep workers and cron running. If payment is pending after the provider confirms it, check callbacks and reconciliation before retrying or recording a manual payment. Do not enable development instant-pay for a public store.
Before switching to live credentials, verify the live account's webhook registration, currency/method availability, and business approval. Paddle webhooks are required for subscription renewals and final refund adjustments; transaction polling alone is not a complete production fallback. Reconfirm the complete flow through an explicitly authorized live validation process. See order operations for manual payment, cancellation, and reconciliation boundaries.