Two-Way, Publisher Provided Static Verification

An ENS publisher desires to send an OOB challenge to its recipient user’s mobile phone using a publisher-provided, static verification value. The publisher elects the ENS provider to verify the recipient’s response to the OOB challenge.

Publisher Completed Pre-requites

The publisher has previously completed the following pre-requisites:

• Deployed its “ECS Admin Login OOB Alert” notification to ENS. The SMS message body for this notification includes the entirety of the OOB notification and does not use any substitution values.
• Added the recipient and subscription information in ENS, including:
• The recipient and subscription information records.
• Recipient’s only contact ID and contact point in the recipient record.
• Recipient’s contact ID assigned for the SMS channel in the recipient’s subscription to the notification.
• Subscribed to receive ENS enterprise events.

Publisher Use Case Options

This tutorial example applies the following four publisher options:

1. Recipient-subscription integration level.
2. Two-way verification.
3. Publisher-provided, static verification value.
4. Published notification message body.

Steps

1. Publisher sends the <OOBValidateRq> notification request to the Enterprise OOB Service provided by ENS.
2. ENS validates the publisher’s request and returns the <OOBValidateRs> message.
3. ENS adds a new OOB session for the publisher’s two-way use case.
4. ENS sends the OOB notification as an SMS message to the recipient’s mobile phone.
5. Recipient responds via SMS text message as instructed by the OOB notification using the static verification value.
6. ENS verifies the recipient’s response containing the static verification value.
7. ENS sends a “90040 – ENS Publisher Feedback” enterprise event confirming that the recipient successfully verified the OOB challenge.
8. Publisher receives the enterprise event and confirms successful OOB verification to recipient user.

Flowchart

Example Messages

OOBValidate Request

This request sample below highlights a minimum sampling of request elements required for this use case.

 <SOAP-ENV:Body>
    <OOBValidateRq xmlns=“http://jackhenry.com/jxchange/TPG/2008”>
        <MsgRqHdr>
            <jXchangeHdr>
                <AuditUsrId>AuditUsrId1</AuditUsrId>
                <AuditWsId>AuditWsId1</AuditWsId>
            </jXchangeHdr>
        </MsgRqHdr>
        <AlrtName>ECS Admin Login OOB Alert</AlrtName>
        <OOBRecipInfoRec>
            <ConsmRecipId>CUS5597765</ConsmRecipId>
        </OOBRecipInfoRec>
        <VerifVal>Yes</VerifVal>
    </OOBValidateRq>
</SOAP-ENV:Body>

OOBValidate Response

<SOAP-ENV:Body>
    <OOBValidateRs xmlns=“http://jackhenry.com/jxchange/TPG/2008”>
        <MsgRsHdr>
            <jXchangeHdr>
                <AuditUsrId>AuditUsrId1</AuditUsrId>
                <AuditWsId>AuditWsId1</AuditWsId>
            </jXchangeHdr>
        </MsgRsHdr>
        <AlrtPkgId>6f26c0bf-1156-55a2-a5e7-df6ffcef06e1</AlrtPkgId>
        <RsStat>Success</RsStat>
    </OOBValidateRs>
</SOAP-ENV:Body>

Referenced and Associated Operations

It is highly recommended that as part of referencing this use case that a user becomes familiar with the following jXchange operations and their function. While the user may elect to not use the listed operation as part of their programming or workflow, knowledge of the operations listed below is essential to understanding the process set forth with this use case.

Detailed information about the operation, the request structure/response, error messages and other useful information can be obtained by clicking the operation name below.