When using Bud as a TSP (Technical Service Provider) and doing full app-to-app authorisation, the customer is returned from the provider directly back to your app. Your app will then need to send all the query and hash fragment parameters to Bud so that we can continue with the payment flow.
Query and fragment parameters should be merged with query taking precedence. If you receive a request /path?a=1#a=2&b=3 then you should perform this request with {"a":"1","b":"3"}. Given the nature of the fragment queries most server side languages will not process these so javascript may be required to correctly gather both parameters.
Regardless of what parameters are present, all of them should be sent to Bud so that we can choose to either continue the connection or to map and record the error.
State, Code and error are the most common parameters you will see, but this object may contain any number of unspecified properties. Currently state is a common property among all authorisation flows and is the current task ID. The state property is not guaranteed for the future of this API contract and will not be treated as backwards incompatible if a new authentication flow does not use it.