As you complete each item and check it off, the state of each checkbox is stored within your browser's cache. You can refer back to this page at any time to see what you've completed so far.
Onerway has designed its sandbox and production environments to function as similarly as possible. Switching between them is mostly a matter of swapping your API keys.
If you're a developer (or had a developer perform an integration for you), also consider the following items before going live. If you're using Onerway through a connected website or a plug-in, most won't apply.
As a developer taking your integration live, complete the following items:
We've created several test valuesPayments API you can use to replicate various states and responses. Beyond these options, perform your due diligence, testing your integration with:
We also recommend you have someone else test your integration, especially if that other person isn't a developer themselves.
Don't wait to go live before discovering that you haven't properly written your code to handle every possible error type, including those that should "never" happen. Be certain your code is defensive, handling not just the common errors, but all possibilities.
When testing your error handling, pay close attention to what information you show to your users. A payment rejection is a different concern than a validation error or server error.
| Error Type | When It Occurs | What to Show Users |
|---|---|---|
| Payment rejection | Insufficient funds, invalid payment method | Payment-specific error message |
| Validation error | Missing required field, invalid format | Field-specific error message |
| Server error | Timeout, 5xx status code | Generic "please try again" message |
Onerway logs every request made with your API keys for internal monitoring. We recommend maintaining your own logs, which are essential for debugging and monitoring your integration. Your own logs serve as a backup if your server has a problem contacting Onerway or you have an issue with your API keys—both cases would prevent us from logging your request.
Regularly examine your logs to make sure they store only the information you need, and not anything of a sensitive nature (for example, credit card details or personally identifiable information).
When creating payment requests, you specify the webhook URL using the notifyUrl parameter. Make sure your production webhook URL is correctly configured and that your production endpoint functions exactly the same as your test endpoint.
While testing your webhooks, also make sure to check that your production endpoint:
Onerway sends webhook notifications when payment events occur. However, notifications might be delayed due to network issues, retries, or high traffic. Design your integration to handle late-arriving notifications gracefully.
If the API response payment result indicates a final state, you can update the merchant order status. The following status codes represent final states:
| Status | Meaning |
|---|---|
S | Success |
F | Failed |
If returning via returnUrl redirect, request the Onerway Query APIPayments API to query the order's final state.
If no result is found, use the following polling frequency to query for transaction results:
Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by logging the event IDs you've processed, and then not processing already-logged events.
Example pattern:
// Track processed events
const processedEvents = new Set();
function handleWebhook(event) {
// Check if already processed
if (processedEvents.has(event.id)) {
return; // Skip duplicate
}
// Process the event
processEvent(event);
// Mark as processed
processedEvents.add(event.id);
}
After receiving a webhook notification, return the transactionId from the notification to Onerway to acknowledge receipt and prevent duplicate deliveries.
After completing this checklist, you're ready to go live. Congratulations! Here's what to do: