There should be more documentation
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/public/server_version
There should be more documentation
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
There should be more documentation
Http-Method: DELETE Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/logout
This API allows the logged in user to change the icon of accounts that they have access to. The icon name must be from the following:
| icon_personalloan_1.svg | icon_everyday_1.svg | icon_homeloan_1.svg |
| icon_termdeposits_1.svg | icon_billpay_1.svg | icon_everydayunlimited_1.svg |
| icon_kiwisaver_1.svg | icon_christmassaver_1.svg | icon_everydaysaver_1.svg |
| icon_freedom_1.svg | icon_kidssaver_1.svg | icon_onlinesaver_1.svg |
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json]Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/accounts/icon\n```json \n{\n \"accountNumber\": \"0020011326\",\n \"iconFileName\": \"icon_personalloan_1.svg\"\n}\n```\n
Empty response with code = 200.\n","operationId":"icon","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/AccountIconReq"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Succeed"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/accounts/account_detail":{"get":{"tags":["Account"],"summary":"This API will return lending account details for the provided account.","description":"
Return lending account details for the provided account. It will contain the expected maturitydate which takes into account the actual payments made.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to access details for account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: https://{server_name}/rsservice/v1/private/account_detail?accountExternalNumber=0011629979&productCode=CALL
Input must be Form-url Encoded We should specify transferableTo,
transferableFrom, billPayable as 'true' or 'false' to enable specific filtering.
All parameters are optional and defaulted to false.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/accounts?transferableTo=abc&transferableFrom=abc&billPayable=abc
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/accounts/forCards?cardTypeCode=0001
This API allows the logged in user to update the display sequence of of the accounts that he/she has access to.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json]Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/accounts/sequence\n```json \n{\n \"accountExternalNumber\": \"0020011326\",\n \"displaySequence\": \"1\"\n}\n```\n
Empty response with code = 200.\n","operationId":"updateAccountSequences","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/AccountSequenceReq"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Succeed"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/accounts/{accountExtNum}/statements":{"get":{"tags":["Account"],"summary":"This API return a list of account statement that belong to the user","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/accounts/0011628559/statements?startDate=2020-06-07&endDate=2023-06-07
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/accounts/000023432/newStatement?fromDate=2020-06-07&toDate=2023-06-07
This API allows the logged in user to change the name of the accounts that he/she has access to. It is idempotent. It does not check if the new name is the same as the old.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json]Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/accounts/rename\n```json \n{\n \"accountNumber\": \"0020011326\",\n \"renameTo\": \"new name\"\n}\n```\n
Empty response with code = 200.\n","operationId":"rename","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/RenameAccountReq"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Succeed"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/accounts/transfer":{"post":{"tags":["Account"],"summary":"This API performs a funds transfer","description":"
This API transfers money between two accounts.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/accounts/transfers```json \n{\n \"fromExternalAccountNumber\": \"string\",\n \"toExternalAccountNumber\": \"string\",\n \"fromProductCode\": \"string\",\n \"toProductCode\": \"string\",\n \"amount\": \"string\",\n \"effectiveDate\": \"string\",\n \"toTransactionDescription\": \"string\",\n \"fromTransactionDescription\": \"string\"\n}\n```\n","operationId":"transfer","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/TransferRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"OK","schema":{"type":"string"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/validate_bank_account":{"get":{"tags":["Account"],"summary":"This API checks if a given account number is in legal format.","description":"
This API returns validation results for a given account number.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/validate_bank_account?bankAccount=abc
There should be more documentation
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/occ-api/v1.0/private/cluster_info
This API can be used to register a biometrics login or reset an existing one. The user must already loggedin. It requires a valid token for the customer and the UUID of the app.
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
This function will create or update the biometrics secret record for a device. The device must have been regiestered before (means the UUID exists).
As upon succcess login, if its a new UUID, a record will be created, this API will expect an existing record for the clientNumber, UUID pair, otherwise will reject the request.
If the record exist, this API will set the encrypted biometrics key so that it can be used for login.
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/biometrics\n```json \n{\n \"uuid\":\"1234567-test\"\n}\nSample Response:\n{\n \"biometricsSecret\": \"3aab5709-304f-4690-9867-fd9feec94502\"\n}\n","operationId":"generateBiometricsSecret","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","description":"Biometrics create/update request","required":true,"schema":{"$ref":"#/definitions/BiometricsGenRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Accepted","schema":{"$ref":"#/definitions/BiometricsGenResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/cards":{"get":{"tags":["Card"],"summary":"This API return a list of cards owned by the logged in user. It returns information such as card number (masked), card name, card surrogate and status.","description":"
Returns list of cards owned by the login user. By default it only returns cards that are at the following 2 status: Active/blocked
There is a query parameter to turn off the default filtering.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API will do a database query to find all the cards that owned by the owner (logged in user or nomineetage user if using client credential mode.). By default,
It will filter by and return the cards that are only at the following 4 status: Active/blocked/lost/stolen.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/cards
Apply an action such as block, unblock to a nominated card.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: https://{server_name}/rsservice/v1/private/cards```json \n \n{\n \"action\": \"unblock\",\n \"surrogateNumber\": \"0000018824\"\n}\n```\n
Empty response with code = 200.\n","operationId":"updateCard","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/CardAction"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/cards/pin":{"put":{"tags":["Card"],"summary":"This API can be used to set PIN for a card.","description":"
Set PIN for a nominated card.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: PUT Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: https://{server_name}/rsservice/v1/private/cards/pin```json \n \n{\n \"pin\": \"2b7e151628aed2a6abf71589\",\n \"surrogateNumber\": \"0000018824\"\n}\n```\n
Empty response with code = 204.\n","operationId":"setPin","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/CardPin"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"type":"string"}},"204":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"500":{"description":"Internal Server Error"}}}},"/cards/{surrogateNumber}/cancel":{"post":{"tags":["Card"],"summary":"This API is to cancel the card.","description":"
This API is to cancel the card.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to update services must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=0}Address: https://{server_name}/rsservice/v1/private/{cardSurrogate}/cancel```json \n{\n {\n \"cancelReasonCode\": \"DC\",\n }\n}```\n","operationId":"cancelCard","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"surrogateNumber","in":"path","required":true,"type":"string","default":"false"},{"in":"body","name":"body","description":"Card cancel request","required":true,"schema":{"$ref":"#/definitions/CardCancelRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/cards/{surrogateNumber}":{"get":{"tags":["Card"],"summary":"This API will return card details for provided surrogate.","description":"
Return card details for provided surrogate.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: https://{server_name}/rsservice/v1/private/cards/{surrogateNumber}
Update card services for provided surrogate and services
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to update services must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: PUT Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: https://{server_name}/rsservice/v1/private/cards/{surrogateNumber}/services```json \n \n{\n \"eCommerce\": \"true\",\n \"paywave\": \"false\"\n}\n```\n
Empty response with code = 200.\n","operationId":"updateService","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"surrogateNumber","in":"path","required":true,"type":"string","default":"false"},{"in":"body","name":"body","description":"Card status request","required":true,"schema":{"type":"object","additionalProperties":{"type":"boolean"}}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/cards/new":{"post":{"tags":["Card"],"summary":"This API will order a new card","description":"
Order a new card linked the provided account.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to update services must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=0}Address: https://{server_name}/rsservice/v1/private/cards/newjson\n\n{\n \"cardTypeCode\": \"0001\",\n \"cardName\": \"S. Squirrel\",\n \"cardDesignCode\": \"0007\",\n \"chequeAccount\": \"1234567890\"\n}\n
Returns list of card types and their designs information
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API will do a database query to find all the cards that owned by the owner (logged in user or nomineetage user if using client credential mode.). By default,
It will filter by and return the cards that are only at the following 4 status: Active/blocked/lost/stolen.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/cards/types
Returns list of card cancel reasons
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API will do a database query to find all of card cancel reasons.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://hostname/SovSE_Mobile_Banking_Server/rsservice/v1/private/cards/cancel-reasons
Returns a card wallet details for google pay / apple pay registration
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to update services must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=0}Address: https://{server_name}/rsservice/v1/private/cards/0000016592/walletRegistrationRequest\n
Returns CF Client AuthToken used by CF's Mobile SDK to perform card actions.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to update services must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=0}Address: https://{server_name}/rsservice/v1/private/cards/getClientAuthToken\n
Returns the terms and conditions resource as either a link or html code
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
Returns the terms and conditions resource. The lookup is done in the following order:
1. If terms.and.conditions.htmlURL property is defined, this will be returned as \"htmlURL\" property.
2. Otherwise, if terms.and.conditions.pdfURL property is defined, this will be returned as \"pdfURL\" property.
3. Otherwise, the contents of a terms_and_conditions.html file are returned as \"text\" property.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/public/terms_and_conditions?mobileAppId123
Status - (A) Accepted or (R) Rejected
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
There should be more documentation
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/public/terms_and_conditions","operationId":"createTermsAndConditionStats","consumes":["application/x-www-form-urlencoded"],"produces":["application/json"],"parameters":[{"name":"status","in":"formData","description":"Session status.\nL = Success And Login,\nS = Success,\nC = Password Fail Complexity\nE = New Password Not Equal\nI = Invalid Access Code\nP = Existing Password Invalid\nA = Accepted\nR = Rejected","required":true,"type":"string","enum":["L","S","C","E","I","P","A","R"]},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"OK"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/client/contacts/street_types":{"get":{"tags":["Contact"],"summary":"This API will return List of street types.","description":"
Get list of Street Types.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/client/contacts/street_types
return the contact details of the client.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/client/contacts
Create or Update Contact Details.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: POST Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/client/contacts```json \n[\n \"phones\": [\n {\n \"effectiveDate\": \"Wed May 29 00:00:00 NZST 2024\",\n \"expiryDate\": \"null\",\n \"surrogate\": \"0000422404\",\n \"contactType\": \"MB\",\n \"countryCode\": \"64\",\n \"networkCode\": \"21\",\n \"number\": \"619267\",\n \"preferredMethod\": \"N\",\n \"priority\": \"0\"\n }\n ],\n \"mobiles\": [\n {\n \"effectiveDate\": \"Wed May 29 00:00:00 NZST 2024\",\n \"expiryDate\": \"null\",\n \"surrogate\": \"0000422404\",\n \"contactType\": \"MB\",\n \"countryCode\": \"64\",\n \"networkCode\": \"21\",\n \"number\": \"619267\",\n \"preferredMethod\": \"N\",\n \"priority\": \"0\"\n }\n ],\n \"emails\": [\n {\n \"effectiveDate\": \"Wed May 29 00:00:00 NZST 2024\",\n \"expiryDate\": \"null\",\n \"surrogate\": \"0000422405\",\n \"contactType\": \"WK\",\n \"address\": \"test@test.com\",\n \"preferredMethod\": \"Y\",\n \"priority\": \"0\"\n }\n \"addresses\": [\n {\n \"careOfName\": \"\",\n \"unitType\": \"\",\n \"apartment\": \"\",\n \"building\": \"\",\n \"streetNumber\": {\n \"from\": \"33\",\n \"to\": \"0\"\n },\n \"effectiveDate\": \"Wed May 29 00:00:00 NZST 2024\",\n \"addressType\": \"S\",\n \"purpose\": \"R\",\n \"alpha\": \"\",\n \"streetOrPostalName\": \"Premier\",\n \"streetType\": \"AV\",\n \"streetDirection\": \"\",\n \"suburb\": \"Point Chevalier\",\n \"city\": \"Auckland\",\n \"state\": \"\",\n \"postCode\": \"1022\",\n \"country\": null,\n \"priority\": 0,\n \"seq\": \"1\",\n \"surrogate\": \"0000422403\",\n \"preferredMethod\": \"N\",\n \"floor\": \"\"\n }\n ]\n
Get field settings on update contact detail page.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/client/contacts/field_settings
Get list of Country Code Types.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/client/contacts/country_code_types
Check that Mobile number is valid.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/client/contacts/validate_mobile_number
This API retrieves the list of document for the user. It supports pagination and filtering.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/documents
This API returns a list of IRD Payment Info which describes how IRD wants bill payment to be formatted for different tax types.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
please read the model 'IRDPaymentInfo' swagger docs for detailed explanation of how the formatting works.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/ird_payment_info
This API returns validation results for a given tax number such as IRD, GST, may include ABN, ACN numbers later. If its valid return only response code 202, otherwise 400.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: {{MB_Server_URL}}/rsservice/v1/private/validate_tax_number?taxNumber=87688321&taxType=IRD
no response for success just header code = 202\n
no response for illegal tax number just header code = 400","operationId":"validateTaxNumber","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"taxNumber","in":"query","description":"Tax Number","required":true,"type":"string"},{"name":"taxType","in":"query","description":"Tax Type","required":true,"type":"string","enum":["IRD","GST"]},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"202":{"description":"Accepted"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/device_management":{"get":{"tags":["Device"],"summary":"This API return a list of devices that are linked to the loggedin user. It will ignore disabled devices. ","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
This API will use the client number (logged in user) to find all the devices associated with max = 10, ignoring disabled ones.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/device_management
This API can be used to disable devices for the current user (primary or secondary) or disable secondary users from using the current device to login.
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/device_management
1. the Logged in user wants to disable the two devices (device-1 and device-2) he/she is registered with.{\n \"devicesToDisable\": [\n \"device-1\",\"device-2\"\n ]\n}\n
2. the logged in user 3006651 is the primary user on the device new_test_66. General_Data API returns this back: \"registeredLogins\": [\n {\n \"userId\": \"testmob1\",\n \"clientNumber\": \"0003078581\",\n \"primary\": false\n },\n {\n \"userId\": \"589279360\",\n \"clientNumber\": \"0589279360\",\n \"primary\": false\n },\n {\n \"userId\": \"3006651\",\n \"clientNumber\": \"0003006651\",\n \"primary\": true\n }\n ]
So there are two secondary users on this device: 589279360 and testmob1.
The logined user '3006651' can disable the two secondary users by calling this: {\n \"secondaryLoginsToDisables\": {\n \"currentDeviceId\": \"new_device_99\",\n \"secondaryClientNumbers\": [\n \"0589279360\",\"0003078581\"\n ]\n }\n}
This API returns the customer's menu structure setting.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/menu_structure
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages/sent?startPositionMemoKey=abc&numOfEmails=20&withMessageSnippet=true
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages/123456
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages/123456
This API allows users to read their inbox (for Sovereign messages either generated by backend system or sent by back officer. )
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages/inbox?startPositionMemoKey=abc&numOfEmails=20&withMessageSnippet=true
This API returns unread messages for the logged in user. Optionally, it may return the first line of each message if query parameter withMessageSnippet is set to true.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages/inbox/unread?withMessageSnippet=true
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/messages
This API returns validation results for a given account number for RBNZ/DSC Submission
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/nominated_bank_account_number/validate?bankAccount=abc
Returns list of Nominated Bank Accounts owned by the login user, and also any possible entries for accounts they are ATO/POA of
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API will do a database query to find all the cards that owned by the owner (logged in user or nomineetage user if using client credential mode.). By default,
It will filter by and return the cards that are only at the following 4 status: Active/blocked/lost/stolen.
HttpMethod: GET Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/nominated_bank_account_number
A Nominated Bank account Number.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, the card to block must be owned by the user.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Headers:{Authorization=Bearer 1b6dbfe7641f87d62d324fdff94a65c, Accept=*/*, content-type=application/json, cache-control=no-cache, Content-Length=61}Address: https://{server_name}/rsservice/v1/private/nominated_bank_account_number```json \n{\n \"nominatedBankAccounts\": [\n {\n \"clientNumber\": \"123456\",\n \"bankAccountNumber\": \"123456789\",\n \"bankAccountName\": \"John Doe\"\n },\n {\n \"clientNumber\": \"123456\",\n \"bankAccountNumber\": \"987654321\",\n \"bankAccountName\": \"Jane Doe\"\n }\n ]\n}\n\n
Empty response with code = 204.\n","operationId":"postNominatedBankAccount","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/NominatedBankAccountRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"type":"string"}},"204":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"500":{"description":"Internal Server Error"}}}},"/password":{"post":{"tags":["Password"],"summary":"This API allows callee to update the password","description":"
This API allows callee to update the password if current correct password can be provided.
This API will check on the client number, current password, and set the password to be the new one if and only if
1. the client number + password (after hash) credentials match existing record.
2. new password satisfies configured password policy.
This API requires a valid token. Standard OAuth security applies.
It also has built-in brute force prevention to block too many failed attempts.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/password```json \n{\n \"currentPassword\": \"F1nzs0ft01\",\n \"newPassword\": \"F1nzs0ft02\"\nn```\nSample Bad request 1: when current password is wrong:
Status code: 400:{\n \"id\": \"passChangeFail\",\n \"type\": \"BadRequest\",\n \"messages\": {\n \"headerNarrative\": \"Device ID is Invalid for Client\",\n \"messageItems\": []\n }\n}\nSample Response: when new password dose not satisfy configured policy. The passed rules will be returned as type:'Info' and the failed policy will be of type 'Error'
Status code: 400:{\n \"id\": \"FailPassPolicy\",\n \"type\": \"BadRequest\",\n \"messages\": {\n \"headerNarrative\": \"New Password does not satisfy password policy.\",\n \"messageItems\": [\n {\n \"code\": \"S619640\",\n \"type\": \"Info\",\n \"description\": \"Must contain at least 5 characters (but no more than 16 characters).\"\n },\n {\n \"code\": \"S619646\",\n \"type\": \"Info\",\n \"description\": \"Must be different to the last 10 passwords you have used.\"\n },\n {\n \"code\": \"S619643\",\n \"type\": \"Info\",\n \"description\": \"Must not have 3 or more of the same character in a row (e.g AAA or 111)\"\n },\n {\n \"code\": \"S619644\",\n \"type\": \"Info\",\n \"description\": \"Must not be the same as your customer number, card number or surname.\"\n },\n {\n \"code\": \"S619614\",\n \"type\": \"Error\",\n \"description\": \"Must contain at least one upper case, one lower case and one numeric character.\"\n }\n ]\n }\n}\n","operationId":"changePassword","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/PasswordChangeRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"OK"},"400":{"description":"Bad request","schema":{"$ref":"#/definitions/ErrorResponse"}},"401":{"description":"Unauthorized","schema":{"$ref":"#/definitions/ErrorResponse"}},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/payees":{"get":{"tags":["Payee"],"summary":"Get list of Payees","description":"
This API retrieves the list of payees for the user. It supports pagination and filtering.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payees
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payees
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payees
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payees/my-payee-ref
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: DELETE Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payees/my-payee-ref
This API retrieves a list of basic information for payees for the user. It supports filtering.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payees/basic_info
This API returns the filterred list of public payees by doing a start with string match.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://occ-api-server.com/rsservice/v1/private/public_payees
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/automatic_payment?automaticPaymentReference=P00000115477
Input must be Form-url Encoded We should specify transferableTo,
transferableFrom, billPayable as 'true' or 'false' to enable specific filtering.
All parameters are optional.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/automatic_payment
Status code: 202\nJSON:\n{\n \"message\": \"This payment required approval from 2 of the following user(s) - Mr Ron McLean, Mr New Vertexon Test. Note: Your approval will be Automatic if you appear in the above list.\"\n}\n
Status code: 202\nJSON:\n{\n \"message\": \"\"\n}\n","operationId":"createAutomaticPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","description":"Automatic payment","required":false,"schema":{"$ref":"#/definitions/AutomaticPayment"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"202":{"description":"Accepted","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}},"put":{"tags":["Payment"],"summary":"Update automatic payment","description":"
Input must be Form-url Encoded We should specify transferableTo,
transferableFrom, billPayable as 'true' or 'false' to enable specific filtering.
All parameters are optional.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/automatic_payment
Status code: 202\nJSON:\n{\n \"message\": \"This payment required approval from 2 of the following user(s) - Mr Ron McLean, Mr New Vertexon Test. Note: Your approval will be Automatic if you appear in the above list.\"\n}\n
Status code: 202\nJSON:\n{\n \"message\": \"\"\n}\n","operationId":"updateAutomaticPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","description":"Automatic payment","required":false,"schema":{"$ref":"#/definitions/AutomaticPayment"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"202":{"description":"Accepted","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}},"delete":{"tags":["Payment"],"summary":"Delete automatic payment","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: DELETE Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/automatic_payment?paymentReference=P00000115477","operationId":"deleteAutomaticPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"paymentReference","in":"query","description":"Payment Reference","required":true,"type":"string"},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"202":{"description":"Accepted","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bill_payment/payee":{"post":{"tags":["Payment"],"summary":"Bill Payment to a payee","description":"
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bill_payment/payee
Status code: 202\nJSON:\n{\n \"message\": \"This payment required approval from 2 of the following user(s) - Mr Ron McLean, Mr New Vertexon Test. Note: Your approval will be Automatic if you appear in the above list.\"\n}\n
Status code: 202\nJSON:\n{\n \"message\": \"\"\n}\n","operationId":"createBillPaymentToPayee","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","description":"Bill payment to payee request","required":true,"schema":{"$ref":"#/definitions/BillPaymentToPayeeRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"202":{"description":"Accepted","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bill_payment":{"delete":{"tags":["Payment"],"summary":"Delete bill payment","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: DELETE Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bill_payment?paymentReference=P00000115477","operationId":"deleteBillPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"paymentReference","in":"query","description":"Payment Reference","required":true,"type":"string"},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"202":{"description":"Accepted","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bill_payment/bank_account":{"post":{"tags":["Payment"],"summary":"Bill Payment to a bank account","description":"
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bill_payment/bank_account
Status code: 202\nJSON:\n{\n \"message\": \"This payment required approval from 2 of the following user(s) - Mr Ron McLean, Mr New Vertexon Test. Note: Your approval will be Automatic if you appear in the above list.\"\n}\n
Status code: 202\nJSON:\n{\n \"message\": \"\"\n}\n","operationId":"createBillPaymentToBankAccount","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","description":"Bill payment to bank account request","required":true,"schema":{"$ref":"#/definitions/BillPaymentToBankAccountRequest"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"202":{"description":"Accepted","schema":{"$ref":"#/definitions/CreatePaymentResponse"}},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bulk_bill_payment/list":{"get":{"tags":["Payment"],"summary":"Get bulk bill payment list","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment/list?status=I
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment/list?status=I
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: DELETE Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment?batchNumber=10174","operationId":"deleteBulkBillPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"batchNumber","in":"query","description":"Bulk bill payment batch number","required":false,"type":"string"},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bulk_bill_payment/upload":{"post":{"tags":["Payment"],"summary":"upload bulk bill payment","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
This API accepts content type: 'multipart/form-data'. This is the only content type that Swagger 2.0 standard accepts for multiple file upload.
It expects one form data element named 'bulkBillPaymentUploadRequest' and with a media type of 'application/json'. The contents of the element is a json string representation of a bulkBillPaymentUploadRequest object.
There is currently no size limit checking at the API level, please use it wisely. The API supported multipart/mixed content type and allows each multipart to have its own type.
However, as the current tools available (Swagger UI, Postman) do not support multipart/mixed, this API is made to support multipart/form-data for uploading.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment/process?batchNumber=10174","operationId":"processBulkBillPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"batchNumber","in":"query","description":"Bulk bill payment batch number","required":false,"type":"string"},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bulk_bill_payment/cancel":{"post":{"tags":["Payment"],"summary":"cancel bulk bill payment","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment/cancel?batchNumber=10174","operationId":"cancelBulkBillPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"batchNumber","in":"query","description":"Bulk bill payment batch number","required":false,"type":"string"},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"Success"},"400":{"description":"Bad request"},"401":{"description":"Unauthorized"},"403":{"description":"Forbidden"},"404":{"description":"Not found"},"405":{"description":"Method Not Allowed"},"406":{"description":"Not Acceptable"},"429":{"description":"Too Many Requests"},"500":{"description":"Internal Server Error"}}}},"/bulk_bill_payment/pre_create":{"post":{"tags":["Payment"],"operationId":"preCreateBulkBillPaymentHeader","consumes":["application/json"],"produces":["application/json"],"parameters":[{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"responses":{"200":{"description":"successful operation","headers":{},"schema":{"$ref":"#/definitions/BulkBillPaymentCreateResponse"}}}}},"/bulk_bill_payment/auto_update":{"put":{"tags":["Payment"],"summary":"auto save bulk bill payment","description":"
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Credentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/bulk_bill_payment
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payment_approvals/details?statusCode=200
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payment_approvals/approve
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payment_approvals/decline
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payment_approvals?fromDate=2019-01-01&statusCode=200
There should be more documentation
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/payment_approvals/status
This API allows the logged in user to cancel a pending payment, such automatic/bill payment.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
HttpMethod: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json]Address: http://localhost:8021/SovSE_Mobile_Banking_Server/rsservice/v1/private/pending_payment/cancel\n```json \n```\n
Empty response with code = 200.\n","operationId":"cancelPayment","consumes":["application/json"],"produces":["application/json"],"parameters":[{"in":"body","name":"body","required":false,"schema":{"$ref":"#/definitions/CancelPendingPaymentReq"}},{"name":"Authorization","in":"header","description":"The Access Token; must use bear token, for example: Bearer xxxxxxxxx","required":false,"type":"string"},{"name":"x-occapi-request-by-client","in":"header","description":"The client number who requests","required":false,"type":"string","x-example":"0003023022"}],"security":[{"customerAPIAuthentication":[]},{"systemAPIAuthentication":[]}],"responses":{"200":{"description":"successful operation","schema":{"type":"string"}}}}},"/pending_payments":{"get":{"tags":["Payment"],"summary":"Get a list of pending payments.","description":"
This API returns a list of payments that are pending, which could be of the following 3 types:automatic_payment, bill_payment or transfer
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/pending_payments
This API can be used to register a PIN or update the pin. It requires the UUID of the app. On succesful login, MB server will register the UUID with the client so pin update/create can work.
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
There should be more documentation
Http-Method: PUT Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/pin\n```json \n
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/transaction_history
There should be more documentation
This API requires System API level authentication (OAuth2.0 Client Credentials). Consumer must supply a valid access token (Bearer).
For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
This API also expects an OCC Client ID representing a Sovereign entity such as dealer or employee. For example, Dealer John Smith has client id = 000023112.
This OCC ID should be passed in as a http header in x-occapi-request-by-client=000023112. This API will only return the requested data if the client
(1) is an employee defined in OCC backend or
(2) has been defined as a key person for an originator that originated the loan application.
When the mentioned header is unset, API will return 400 with an error message: Http header:x-occapi-request-by-client is required for this API.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/login_info
This API returns validation results for a given account number.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
After authorization check, this API will based on the 'response' value passed in to decide how much information to retrieve and return.
Http-Method: POST Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/transfer/create_transfer_payment
This API returns validation results for a given account number and is deprecated by the /account API please use that instead..
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
After authorization check, this API will based on the 'response' value passed in to decide how much information to retrieve and return.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/transfer/transfer_to_account
This API returns validation results for a given account number.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
After authorization check, this API will based on the 'response' value passed in to decide how much information to retrieve and return.
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/private/transfer/transfer_from_account
Currently this API returns the logged in user's GST number and names.
This API supports two OAuth 2.0 flows: Customer API level authentication (OAuth2.0 Resource Owner Flow) and System API level authentication (OAuth2.0 Client Crendentials).
Note Resource Owner is the preferred way, as its much safer to restrict access based on who actually signed in -- the resource owner.
Client Credentials authentication is supported but NOT recommended -- the trusted client uses the header x-occapi-request-by-client to inform the API who is accessing it.
That means the authenticated client can impersonate any customer. Allow this only when the client can be completely trusted -- ie an authorized channel partner who holds its own certificates and credentials etc.
API Consumer must supply a valid username password to the tokenAPI in exchange for an access token (Bearer) to access this API
The access token must be supplied in the header as a Bearer token. For example: Authorization:Bearer cbc77598e7777898a9fcbbeee24adfa4
When Resource Owner flow is used, authorisation is done based on the user's permission. The access token issued by the token API identifies the user. So the API will make sure only operations associated with that user will be allowed.
For example, Customer A will not be able to transfer money from account B that he has no authorities to access.
When Client Credential flow is used, authorisation is checked against the x-occapi-request-by-client header value.
There should be more documentation
Http-Method: GET Content-Type: application/json Headers: {Authorization=[Bearer 4f1ccf54a09fb92031b67c54f9b45011], Content-Type=[application/json], x-occapi-request-by-client=[0030037496]}Address: http://mobile-banking-server.com/rsservice/v1/public/users/info