Testing checklist
Now that you've completed your integration, it's time to test it.
Below is a list of manual test cases to run through. If each of them passes, your integration is ready to be deployed in production.
Before you start, please read the following section about how to force orders to be accepted or rejected for testing purposes.
Bypassing Hokodo's Fraud and Credit Checks to aid testing
When a Buyer wishes to pay with Hokodo, there are a number of checks that Hokodo makes behind the scenes. These checks are to prevent fraud and to determine what payment terms are available to the Buyer. Read more about them in the In Depth Knowledge section.
Hokodo provides the ability to bypass these fraud and credit checks in our Sandbox environment in order to simulate the full variety of scenarios that can occur during live usage.
To set up this bypass, the email address of the test Buyer needs to include a certain substring.
The first substring is prefixed with paymentplan. Payment Plans denote the payment terms that are calculated by our underwriting engine.
The second substring you can use is prefixed with dp_fraud. Once a Buyer has accepted a Payment Plan, a Deferred Payment (or dp) will be created and our fraud engine will assess the Order.
The full list of available email strings can be found in the tables below
Payment Plan Test Emails
| Pattern | Result |
|---|---|
| paymentplan_offered | The Buyer will be offered all available Payment Terms |
| paymentplan_declined | The Buyer will not be offered any Payment Terms |
| paymentplan_partly_offered | The Buyer will be offered some Payment Terms, but not all of them |
Deferred Payment Test Emails
| Pattern | Result |
|---|---|
| dp_fraud_accepted | The Deferred Payment will be accepted |
| dp_fraud_rejected | The Deferred Payment will be rejected after a fraud review |
| dp_fraud_customer_action_required | Hokodo will require more information from the Buyer before accepting or rejecting the Deferred Payment |
| dp_fraud_pending_review | The Deferred Payment will be the subject of a manual review by a member of Hokodo's fraud team |
Examples
To test the happy path, you need to guarantee that payment terms are offered, and the fraud review is automatically passed. Create a User with an email address like paymentplan_offered-dp_fraud_accepted@your-domain.com to do this.
To test the behaviour of your checkout when a Buyer is not eligible for payment terms, create an Order using a User whose email address is something like paymentplan_rejected@your-domain.com.
Other examples of where a fraud bypass may be useful are covered in the testing scenarios, later in this document.
Using email aliases
Many email plaforms support email subaddressing whereby you
can append a + character to an email address and it will allow you to use one email account to be aliased multiple times.
This is really useful when combined with Hokodo's email bypass feature. For example, you can set a User's email address as
test+paymentplan_offered-dp_fraud_accepted@your-domain.com
or
test+paymentplan_rejected@your-domain.com
to check different scenarios, but you'll still only require one email account (test@domain.com)
Email Bypass can only be used in our Sandbox environment
This fraud bypass functionality is not available in Production, where Payment Terms and fraud checks are always based on the status of the real company making the purchase.
Test Suite 1: Happy path
Run through the checkout process on your site as a buyer. Use a company that is accepted for payment terms.
There is a set of checks we will carry out to ensure certain details are in place. We've listed these below.
You can make use of the Developer Dashboard to see logs and track the progress of your test Orders.
Check 1.1: Buyer phone number is submitted
As a buyer, enter a phone number at the correct stage of the journey.
Our Solutions Engineer will check that the User creation request is logged with the phone number included.
Why do we check this?
In a minority of cases, we may need to contact the buyer to understand any unusual behavior in order to approve the order. We will also need to contact them in cases of nonpayment.
Check 1.2: Each Order item has a category
Once the order has been submitted, we will check that each item in the order has a category.
Why do we check this?
Our fraud decision engine relies on being supplied product categories in the order. The Developer Dashboard will allow you to confirm that Product Categories were saved correctly.
Check 1.3: Shipping an accepted Order
Create an Order with a User whose email address is [something]+dp_fraud_accepted@[your-domain]. This will override the standard Hokodo fraud decision engine and automatically accept the Order.
When you have completed the Checkout process, verify that the Order is ready to be shipped in your back-office.
More detail
When the buyer hits 'Confirm' in the checkout, a Deferred Payment object
is created in Hokodo's back-end, and you will receive a webhook at the "notification" URL you sent
when creating a Payment Offer.
Why do we check this?
Buyers cannot receive their Order, and Merchants cannot receive their money until a Deferred Payment is accepted by Hokodo. So it's crucial to check that this scenario works as expected.
Check 1.4: Our API is notified about captures
Once the webhook notification that a Deferred Payment is accepted has been recieved, proceed with the shipping process in your back-office, which should apply a Capture request.
The result is that the order status in the Merchant Dashbord should update to Captured.
Why do we check this?
We need to know about captures in order to trigger our payouts to you.
Check 1.5: Our API receives your Order unique_ids correctly
Check the Merchant Dashboard to find the Order and confirm that we're receiving the unique_id in the Order object correctly. This should be the ID you use
to refer to the order in your system.
Why do we check this?
We need a shared language to discuss orders with you and your customers.
Check 1.6: Invoices get uploaded to us
Your system should have uploaded an invoice to our Order Documents endpoint. We will check that we have received it correctly.
Please note that invoice uploads are operationally mandatory for going live with Hokodo.
Why do we check this?
We will not make a payout unless unless you upload an invoice to us. When we are discussing an order with a customer or chasing payment, we’ll need the invoice to hand. These must be automatically uploaded else the operational burden is too great on our respective teams.
Test Suite 2: Order Quantities
These tests check that the quantities on the Order object are being submitted correctly.
Check 2.1: Orders can be modified prior to checkout
If the user modifies the order before the checkout is complete (creating the Deferred Payment) the order can be kept up to date with PATCH requests. To test this is implemented correctly, as a user, checkout to our payment page, then select Cancel, return to your store, edit the order. Then return again to the payment page.
Find the Order in the Merchant Dashboard's Orders page and check the order totals have updated and are correct.
Why do we check this?
We need to ensure if the order is changed, the new version is the one that a payment is set up for with Hokodo.
Check 2.2: Tax, shipping and discounts all agree with the total_amount
Create an order with discounts, shipping, and tax all in the order. Go to the Hokodo payment page.
Check that the values are correct.
Why do we check this?
If you have pre-sale (promotional) discounts and tax applied to your orders, verify that these are being sent correctly to our order endpoint.
Test Suite 3: Order Rejected
These tests check everything works correctly in the case that we can't offer payment terms for a particular order.
Check 3.1: Rejected Orders are handled correctly
Rejected Orders
Create an Order with a User whose email address is [something]+paymentplan_rejected@[domain]. This will override Hokodo's scoring engine and make the Buyer's Company ineligible for payment terms.
Verify that your site does not offer the Buyer the option to pay with Hokodo.
Why do we check this?
If the customer has been refused payment terms for this order, they should not be able to proceed to payment.
They need to see the rejection reason so they understand why they have not been able to use Hokodo’s solution on this occasion.
Partially Rejected Orders
Create an Order with a User whose email address is [something]+paymentplan_partly_offered@[domain]. This will override Hokodo's scoring engine and make the Buyer's Company eligible for some payment terms, but not all of them. For example, they may be eligible to pay in 30 Days, but not to pay in 60 Days.
Verify that your site only offers the option to pay with Hokodo for the payment terms they qualify for.
Not all Merchants have multiple payment terms
Depending on the agreement between you and Hokodo, not all payment terms are available to your Buyers. If your agreement with Hokodo only includes one possible payment term (for example, Pay in 30 days), then you should skip this Partially Rejected Orders test.
Check 3.2: A rejected or pending_review Deferred Payment cannot be shipped
Create an Order with a User whose email address is [something]+dp_fraud_rejected@[your-domain], which stops the fraud engine from automatically moving the order to Accepted.
When you have completed the Checkout process, verify that the Order cannot be shipped in your back-office.
Repeat this test for the following User email addresses. In each case, it must not be possible to ship the Order.
| Buyer Email |
|---|
| [something]+dp_fraud_customer_action_required@[your-domain] |
| [something]+dp_fraud_pending_review@[your-domain] |
Why do we check this?
If the fraud review rejected the order, the customer is suspected of fraud and should not receive the goods.
Test Suite 4: Refunds and voids
These tests check that your back-office can record refunds and voids correctly in our API.
Check 4.1: Voids are recorded correctly (optional)
After the customer has checked out, use your back-office to cancel some of the line items of the order (eg. because those items weren't available to ship). If you have implemented the void endpoint, check that:
- the remaining
authorisationon the Deferred Payment has reduced accordingly. - a
"type": "void"event can be seen on the Deferred Payment
Why do we check this?
If you void remaining authorisation then that makes that authorisation available for other orders. If you don't do this, it will expire at a later date. In any case, we won't charge the customer since that value was never Captured.
Check 4.2: Refunds are recorded correctly
After the customer has checked out, capture the Deferred Payment. Then, use your back-office to record a refund (some of the items could be returned, or you may have agreed to a credit note). Check that:
- the
protected_capturesorunprotected_capturesvalue has decreased accordingly in the Deferred Payment response. - a
"type": "refund"event can be seen on the Deferred Payment
Why do we check this?
We need to be informed of refunds in order to adjust the amount we charge the buyer when the payment becomes due (the total Captured).
Next up: Ship it!
If you've run through these test cases and all the checks come out green, you're ready to deploy to production. Congratulations!
You will receive an email from our integration team detailing how to get your API key for Production.