SOAP Authentication Update for iPay

What are you trying to build?

Migrate jXchange Authentication from WS-Security to OAuth 2.0 for iPay

Q1

Can one client ID be authorized for multiple institution routing IDs? Unlike host-jxchange (single INST_RTG_ID env), bill-pay-ipay-api can serve several routing IDs from one deployment — the Inst Routing Id Mapping configurable property maps a user identifier to an InstRtId, substituted into ns:InstRtld per call. JH authorizes a client to an institution.

Q2

What is the DMZ hostname under OAuth? Neither the email nor the docs name one — both give only jx.jackhenry.com. Gates story 3.

Q3

Why does the DMZ still accept WS-Security, and when will the cutover actually be enforced? Determines how much runway our test environment has.

Q4

Is the SilverLake DMZ tenant already authorized for the BilPay messages? Or does iPay need its own DMZ authorization? A static public key is acceptable for DMZ, so this is the only thing between us and a DMZ proof-of-concept.

Q5

Confirm the amendment model: reuse the FI’s existing client ID and authorize the BilPay* operations, rather than issuing a second client.

[Return to Manage Case](javascript:submitAction_win0(document.win0,‘JHA_CASE_SS_RPT_RETURN_TO_CASE’):wink:

Environment

What did you try?

Just researching at this time

What happened?

  • Dev has some questions regarding the SOAP Authentication Update

Safe-posting confirmation

  • I removed tokens, secrets, private keys, passwords, SSNs, account
    numbers, customer data, and institution-confidential configuration.
  1. Can one client ID be authorized for multiple institution routing IDs? Unlike host-jxchange (single INST_RTG_ID env), bill-pay-ipay-api can serve several routing IDs from one deployment — the Inst Routing Id Mapping configurable property maps a user identifier to an InstRtId, substituted into ns:InstRtld per call. JH authorizes a client to an institution.JH Response: This question will need to be answered by the iPay Integration Support team. Please email them at ipayintsupport@jackhenry.com.
  2. What is the DMZ hostname under OAuth? Neither the email nor the docs name one — both give only jx.jackhenry.com. Gates story 3.JH Response: There are two endpoints for the new OAuth environment. These are discussed on the Development Using SOAP Page: Development using SOAP | jXchange - SOAP API | Jack Henry Docs Token request: https://login.jackhenry.com/a/oidc-provider/api/v0/token API request: Service
  3. Why does the DMZ still accept WS-Security, and when will the cutover actually be enforced? Determines how much runway our test environment has. JH Response: We elected to offer a cutover grace period. Each credential method uses a different endpoint. Information on cutover dates is provided on our SOAP Authentication Update Page: SOAP Authentication Update | jXchange - SOAP API | Jack Henry Docs
  4. Is the SilverLake DMZ tenant already authorized for the BilPay messages? Or does iPay need its own DMZ authorization? A static public key is acceptable for DMZ, so this is the only thing between us and a DMZ proof-of-concept.JH Response: iPay uses its own setup and integration path. You will not be able to use SilverLake Client Id credentials to test billpay APIs.
  5. Confirm the amendment model: reuse the FI’s existing client ID and authorize the BilPay* operations, rather than issuing a second client.JH Response: A second client id will be required for Billpay APIs due to the different integration path it uses to connect to jXchange Service Gateway.