Payment Gateway Integration Checklist for Philippine Websites
Connect payments to order states, verified notifications, retries, and reconciliation before treating checkout as finished.
Rootscratch ·
A payment integration is complete when your business can reliably connect a provider's payment result to the correct order. The checkout button is only the visible beginning. Your server needs to handle pending payments, failed notifications, duplicate events, and later refunds.
For a Philippine business, first confirm that the chosen provider supports your merchant account, settlement needs, currency, and required payment methods. Verify these directly with the provider before promising a particular wallet or bank option in the website scope.
Create the order before redirecting the customer
Assign a stable order reference and record the expected amount and currency on the server. Use that record when creating the payment request. Do not trust a total supplied by browser JavaScript without checking it against the order.
Save the provider's reference alongside your own. Staff should be able to trace a payment from either side without searching by a customer's name alone. Keep secret credentials on the server and separate test configuration from production.
Verify payment independently of the return page
A visitor may close checkout before returning to your site, or manually open a success URL. Treat that page as a place to display the known order status, not as proof of payment.
Use authenticated provider notifications and the provider's documented verification process. Stripe's webhook documentation describes signature verification and duplicate-event handling. Apply the equivalent documented controls for whichever provider you select; implementations are not interchangeable.
Expect retries and missed notifications
Record processed event identifiers and make repeated delivery safe. If the same successful-payment event arrives twice, it should not ship two orders or issue two bookings. Keep the event-processing step small, and move slower follow-up work into a recoverable queue.
PayMongo documents webhook retries and a payment-status retrieval path for interruptions. This is a useful reminder to design reconciliation: a scheduled or staff-triggered check that compares unresolved orders against the provider's current record.
Agree on business states with the team
| State | What the website should explain |
|---|---|
| Awaiting payment | The order exists but is not yet paid |
| Processing | The final provider result is still being checked |
| Paid | The verified result matches the expected order |
| Failed or expired | The customer needs a clear next action |
| Refunded | The refund record and order record remain connected |
Decide separately when fulfillment starts. Payment received and order delivered are different events. Staff may also need to handle a partial refund without losing the original transaction history.
Before launch, test a successful payment, a declined attempt, a closed browser, duplicate notifications, a temporary server outage, and a refund. Confirm that customer messages match the actual saved state throughout the process.
Rootscratch provides website development and API automation for payment-connected workflows. Provider approval and available methods remain subject to the chosen provider; a website integration does not create a merchant partnership or guarantee account eligibility.