B2G interface with the PPSR
These documents and tips below help you configure your B2G interface. They help with developing, testing, troubleshooting, or if you are looking to enhance your existing interface.
See B2G documents and Versions of the B2G interface for more information about the different B2G versions.
The next PPSR release (R8.9) will allow B2G clients to opt-in to receive availability checks on 4 key services within PPSR:
- Payment
- Registration
- Search
- Search certificate.
There will be 3 health statuses next to each service:
- 'Available'
- '*Available – low data' (the service is available but there is insufficient data during periods of low usage to reliably confirm full availability status)
- 'Unavailable'.
The enhancements are available on B2G interface versions 2016 and 2022.
The enhancements are not available on B2G interface versions 2011 or 2015.
There are no changes to the WSDLs for this change. The updated interface specifications are available below.
Opt-in to receive the PPSR availability information
System administrators, B2G developers or network / IT administrators please email enquiries@ppsr.gov.au with the following information:
Subject: B2G PPSR availability opt-in
- Environment to be updated (Production / Discovery)
- Production account name and number
- Discovery account name and number
- Requestor’s name
- B2G interface version (e.g. 2022)
B2G interface version 2022
B2G interface version 2016
B2G interface version 2015
B2G interface version 2011
From time to time, we will update the current version of the B2G interface to a new version.
We use Web Services Description Language (WDSL) to provide the different versions.
We currently support the following 4 versions of the B2G interface, including current and previous releases:
- Version 2022
- Version 2016
- Version 2015
- Version 2011
We communicate and manage changes with PPSR B2G clients to provide adequate transition periods.
Functions supported and not supported by B2G interfaces
The table below shows the main functions available via the B2G channel.
Refer to the specification documents in the related documentation row for more information.
Interface version 2016 and 2022 | Interface version 2015 | Interface version 2011 | |
---|---|---|---|
Supported functions |
|
|
|
Related documentation |
|
|
|
Functions not available through the B2G interface, include:
- account management
- user management
You can choose which functions to implement in a way that makes business sense for your organisation. The only mandatory B2G functions are ping and change B2G password.
The written-off codes provided by the National Exchange of Vehicle and Driver Information System (NEVDIS) are unformatted. The PPSR will format this data for search certificates and verification statements generated as PDFs, as well as on all on screen search results via WebUI. B2G clients are provided the unformatted data through XML.
An example of the response returned would be:
- I01BI05BI06B, NSW, 19 Mar 1997, Repairable Write-off
To format this code these details need to be broken down into short 4 character elements.
- I01B
- I05B
- I06B
Each element would then represent the 3 components of the damage codes.
I01B | |
---|---|
I | Impact (Incident Type) |
01 | Passenger front (Damage Location) |
B | Light panel (Damage Severity) |
Once the codes have been formatted they should then be displayed as per the following:
NSW, 19 Mar 1997, Repairable Write-off
I01B | Impact | Passenger front | Light panel |
I01B | Impact | Passenger rear | Light panel |
I01B | Impact | Passenger side | Light panel |
The full table of written off codes can be located at the Updates to written-off vehicle information.
Test data for use in the Discovery environment:
TIP: If you use the search certificate or verification statement generated by the PPSR in PDF format you will not be required to make any changes, to display the additional written-off data.
The above changes only relate if you display the search results including the NEVDIS information in your B2G interface.
Each line of NEVDIS information returned during a search will contain a string of code which needs to be broken down and interpreted.
If this is the case, you will be required to format the codes returned in your XML response.