Separate account acceptance from API access.
Describe the entity, exact catalog, customer destinations, order values and payment-to-delivery timing. State whether you need one-time purchases, recurring charges, delayed capture, partial refunds or multiple storefronts. A test API key is not permission to process the business in production.
Ask who provides the merchant account, gateway, customer support and settlement reports. If the checkout involves a second purchase or converts funds to crypto, document that flow explicitly. Confirm what appears on the customer’s statement and who handles refunds and disputes.
Choose how card details enter the payment system.
Discuss a hosted checkout or provider-hosted payment fields with your developer. Stripe’s integration security guide explains that sending card information directly to the provider can reduce PCI obligations; security responsibility still depends on the integration and business. Ask your selected provider what validation is required.
Use its supported approach for saved payment methods and recurring billing. Keep production credentials out of client-side code and introductory assessment forms. Separate test and live configuration, limit access and document who owns credential changes and operational support.
Make payment state drive the order state.
Define when an order is pending, paid, ready to fulfill, refunded or disputed. A browser returning to a thank-you page should not be the only evidence that payment succeeded. Ask the gateway how authenticated server notifications or status checks confirm the final state.
Stripe’s webhook documentation addresses signature verification, duplicate deliveries and events arriving out of order. Use the equivalent guidance for the selected gateway. Your integration should handle retries without charging twice or shipping twice and should retain a traceable link between orders and payment identifiers.
Include operations in the launch plan.
Test approved and declined payments, interrupted sessions, asynchronous confirmation, partial refunds and recurring failures. Check which actions staff can perform in your own dashboard and which require the provider’s portal. Give support a way to investigate an order without exposing sensitive data.
Reconcile orders, gateway transactions, fees, reserves and deposits using a common reference. Confirm settlement currencies and reporting access before committing to the build. Alderwell provides advisory and referral support; the partner controls underwriting and processing, and your development team owns the implementation.
Your preparation checklist
- Entity, catalog, markets and complete transaction requirements
- Merchant account, gateway and support responsibilities
- Hosted checkout or fields and required security validation
- Payment-state, retry, refund and recurring-event handling
- Test cases, reporting, reconciliation and maintenance ownership
Common questions
Can a Next.js or headless store use a high-risk payment gateway?
The framework does not determine merchant eligibility. Confirm that an accepting provider has a supported integration suitable for your architecture and customer journey.
Should I build the checkout before approval?
Define requirements and assess documentation early. Delay a provider-specific production commitment until business acceptance, account terms and the intended integration are clear.
Does hosted checkout remove every security obligation?
No. It can change the scope of how card data is handled. Confirm your responsibilities and validation requirements with the provider for the actual integration.
Can I reuse saved cards when changing providers?
Ask both providers whether a supported token migration exists. Tokens may be tied to a particular service or configuration; customers may need to supply payment details again.