Payment integration kickoff checklist · domestic PG and simple pay

Separate test kickoff from production activation. Confirm what can be developed with the provider's test keys and environment, and prepare the relevant merchant identifier and access. Open real payments only after confirming the contract, review, production credentials, and activation of that method. For a method still under review, distinguish what can be tested now from when it can go live and reflect both in the build schedule. Check that the settlement account, tax invoice conditions, and settlement cycle read the same in the contract and in the console. The domain that opens the payment window and the server address that receives the result must be registered with the provider in advance, so submit both the development and production addresses together. Decide who holds the production keys and where they live before kickoff, so they never reach version control. Features with a separate review — billing keys, escrow — get their application date set in the kickoff week. Fix the integration document and SDK version at the same time: providers often publish several versions at once, and without naming the authoritative one the app and the server get built against different contracts.

Draw the order states first. Name every state through payment requested, authorized, authorization failed, cancelled, partially cancelled, refunded, and settled, and mark who causes each transition. Decide here how many partial cancellations are allowed and what the cancellation unit is for an order that ships in parts. Write down how the unique key on each request is built and what a repeated key returns. Settle the handling of a transaction with no response before writing code too: when and how often to ask the provider's inquiry contract for the state, and which state an unresolved transaction rests in and who is alerted. Decide which side determines the amount. For orders mixing coupons and points, recompute the final amount on the server and match it against the authorization request; if they differ, the authorization is not sent.

Establish the normal flow with a successful payment, then exercise failure and exception paths. Include declines, limit exceeded, abandoned authentication, checkout drop-off, lost notifications, and duplicate notifications, and confirm which cases the provider's sandbox can reproduce. For each, check which state the order rests in, what the customer sees, and that a retry does not produce a second authorization. Run partial cancellation and full refund against the same transaction in both orders. Send a request with a mismatched amount and a second cancellation against an already cancelled transaction, and read the responses. If you accept several methods, run the whole list again per method, because the cancellation window and refund procedure differ by method. A service shipping both an app and a web front end runs the list in both, since the return path differs when the payment window opens inside the app rather than in an external browser, and drop-off handling changes with it.

People need working screens before launch day. Open a lookup for support first — find a transaction by order number and read request, authorization, notification receipt, and cancellation in time order. Switch on the per-provider view of authorization failures and error trends, along with the path that alerts an owner when it leaves the expected band. Split refund execution rights only after an approval path exists. Write down where provider incidents are filed and who replies, with contact details attached. On the first day of live traffic, run one real authorization and one real cancellation and confirm both appear in the settlement file. What you are capturing at that point is not the matching rules but the fields the matching will use — record the column names the transaction identifier, approval number, and fee timing arrive under, and the settlement owner will not have to ask again. Keep a single page at the support desk naming the screen to open first for each symptom and the owner to escalate to.