Skip to content

Simulate employer issues in sandbox

Employer issues are raised when something goes wrong that only a human on your side can fix, such as a fund rejecting a member registration. Most of them are raised by responses from external integrations, and in sandbox those integrations are simulated rather than really contacted, so the responses that would raise an issue never arrive on their own.

The sandbox debug tool lets you choose the next simulated SuperStream response so it comes back as a rejection. The rejection then flows through exactly the same code as a real one, raising real issue records and firing the same webhooks your production integration will receive.

INFO

This only works for sandboxed partners. Nothing here affects production data, and the response dropdowns do not appear for a partner that is not sandboxed.

Choosing a response

Open a sandboxed onboarding session embed and click the Sandbox badge to open the debug tool. Under the fund membership section you'll find a dropdown for the registration response and one for the verification response.

Pick a scenario from the relevant dropdown, then complete the onboarding session as you normally would. Your choice takes effect immediately. When the simulated fund response is generated, it comes back as the rejection you chose instead of a success.

Scenarios are set against the employer, not the employee, even though you set them from inside one employee's session. Any employee of that employer picks up the chosen scenario.

Available scenarios

ScenarioOutcome codeRaises
Employer not participating in fundSUPER.GEN.CNTRBTN.22employer_not_participating_in_fund and failed_fund_registration
Registration rejected by fundSUPER.GEN.CNTRBTN.12failed_fund_registration
Membership verification rejectedSUPER.GEN.MEMBER.4invalid_super_fund_membership

The first scenario raises two issues, and that is deliberate rather than a duplicate. The employer-scoped issue says the employer has no arrangement with the fund and is raised once per fund. The employee-scoped issue says this particular employee did not get registered and is raised once per employee. You need to resolve both, and they resolve independently.

The outcome code is shown next to each scenario in the tool, and appears in the issue's metadata, so you can match what you chose against what your integration receives.

WARNING

The two registration scenarios currently only raise issues when the employee is being registered as a new member of a fund. If the employee entered an existing member number and is being retained with their current fund, the rejection is simulated but no issue is raised yet. Test the registration scenarios with an employee choosing a fund they are not already a member of.

Verification rejections apply to APRA funds only. Choosing the verification scenario has no effect on a self-managed super fund, and the choice stays in place for the next APRA verification rather than being used up.

Timing and expiry

Each choice is used once, by the next matching message for that employer, and is cleared as soon as it is used. Choose it again to produce a second rejection. The dropdown reads its state when the tool opens, so reopen it to see a choice that has since been used or expired.

Simulated registration responses are delayed by between 30 seconds and 3 minutes, mimicking a real fund's turnaround. That means you can choose a scenario just after completing the session and still catch the response, but it also means the issue will not appear the instant the session completes.

Verification timing depends on whether the employee is a new or existing member of the fund. For a grow (a new member registration), the first verification is deliberately held back about 5 minutes so the registration lands first, so a verification rejection on a grow takes roughly 5 to 8 minutes end to end. For a retain (an existing member), verification happens immediately and comes back within the usual 30 seconds to 3 minutes. Without accounting for this, a verification scenario on a grow will look broken after a couple of minutes of nothing.

A choice you never use expires after an hour. A dropdown showing anything other than Success also shows the time that choice has left, and you can clear it early by setting it back to Success.

The registration and verification dropdowns are independent, so you can choose one of each and have a single session produce both a failed registration and a rejected verification.

Testing the resolution side

Issues resolve themselves when the underlying problem is fixed, which is what clears the notification in your own UI. Once an issue is open, you can produce the employer_issue_resolved webhook by making the change that resolves it.

failed_fund_registration resolves when the employee makes a new fund nomination, so set the dropdown back to Success and re-onboard the employee.

employer_not_participating_in_fund resolves when the employer's default fund or fund configuration is updated, so change the employer's default fund.

invalid_super_fund_membership resolves when a successful verification lands for the same employee and fund, so set the dropdown back to Success and re-onboard the employee.

Prerequisites

Employer issue webhooks are off by default. Ask your SuperAPI contact to enable them for your partner account, otherwise the issues will be created but you will not be notified about them.

The membership verification scenario additionally needs member verification enabled for your partner account. Ask your SuperAPI contact if the verification scenario appears to do nothing.

Abandoned sessions

One issue kind needs no scenario at all. If an employee abandons a sandboxed onboarding session without choosing a fund, an undefaulted_abandonment issue is raised, the same as it would be for an employer with no stapling connection in production. Abandon a session to produce one.

Getting help

Stuck with something and need help? Please contact us at support@superapi.com.au or by phone on 0405 472 748 (Sam). Have you setup a shared Slack or Teams channel with us? If not, please reach out so we can provide realtime support.

The future of super is embedded