Fix Readme
Abstract
This document contains version 3.2.9 release information for Financial Transaction Manager for Digital Payments for Multiplatforms.
Content
Financial Transaction Manager for Digital Payments 3.2.9 Release Information
Contents
Common Across Releases
3.2.9.0 Release
... 3.2.9.0 interim fix 1
... 3.2.9.0 interim fix 2
... 3.2.9.0 interim fix 3
... 3.2.9.0 interim fix 4
... 3.2.9.0 interim fix 4.1
... 3.2.9.0 interim fix 5
... 3.2.9.0 interim fix 6
... 3.2.9.0 interim fix 7
... 3.2.9.0 interim fix 8
... 3.2.9.0 interim fix 9
3.2.9.1 Release
... 3.2.9.1 interim fix 1
When you upgrade a fix pack or interim fix, in addition to the changes in the level that is being upgraded to, be sure to review the changes in the intermediate fix packs or interim fixes.
Examples:
- Currently, at level fix pack 1 and upgrading to level fix pack 3, review the changes in fix pack 2 and fix pack 3.
- Currently, at fix pack 1 / interim fix 1 and upgrading to fix pack 1 / interim fix 3, review the changes in fix pack 1 / interim fix 2 and fix pack 1 / interim fix 3.
| Back to top |
Common Across Releases
|
Known Issues
Internet Explorer (IE) Issue
FTM does not set the "Cache-Control" and "Pragma" headers on certain responses even if they are defined in the "HTTP Response Headers" section in System Properties screen.
The issue happens only on Internet Explorer browser because of a known Internet Explorer defect, which has no immediate fix date available from Microsoft.
Work around:
Use Firefox or Chrome supported versions to have all headers properly set on all responses
WebSphere Application Server 9.0.x update issue
Automated Deployment Utility workaround:
The interim fix components to update need to be first uninstalled. The tokens file, for example pfs_deploy.xml, contains those interim fix components to update. These components appear in the <install> </install> section. You also need to add these same components in the <uninstall> </uninstall> section.
Before the Console WAR modules are updated, stop the FrameworkUI_EAR application and then proceed as normal. The Engine modules can be updated as normal.
The minimum EWS version required for FTM 3.2.9 is EWS 4.3.
The following is a list of supported EWS notifications and supported EWS SOAP requests.
Supported EWS notifications: OnTokenStatusChangeNotification4.0, OnCustomerChangeNotification4.2, OnPaymentProfileStatusChangeNotification, OnNewPaymentNotification4.0, OnOrganizationsChangeNotification4.0, OnPaymentRequestChangeNotification2.4, OnNewPaymentRequestNotification4.0, OnPaymentStatusChangeNotification4.3 Supported EWS requests: AddPaymentRequest4.1, ChangePaymentRequestRequest4.0, ChangePaymentStatusRequest4.0, DeletePaymentProfileRequest, GetCustomerEventDetailsRequest4.0, GetOrganizationsRequest4.0, GetPaymentRequest4.3, GetPaymentRequestDetailsRequest4.0, GetPendingActivityForTokenRequest3.2, GetTokenHistoryRequest4.1, GetTokenStatusRequest4.2, RegisterTokenRequest4.0, RemoveTokenRestrictionRequest3.10, RequestPaymentsRequest4.0, RestrictTokenRequest3.10, UnregisterTokenRequest3.10, UpdateBusinessPaymentProfileRequest4.0, UpdatePersonalPaymentProfileRequest4.0, ValidateRecipientRequest4.2 Supported EWS RESTful requests: zpss/v1/active-profiles
Fix list and new feature summary
For a list of fixes, see Version 3.2.9 Fix List for Financial Transaction Manager for Digital Payments.
Data Setup Utility
The following documentation describes the changes for the data setup utility (DSU) and the import and export workbooks:
- DSUmigration_v3.2.9.pdf
- DSUMigrationBR_v3.2.9.pdf
These documents are provided in the entitled documentation fix pack. For more information about getting this fix pack, refer to the Entitled Documentation section.
Database migration
For database migration instructions, refer to the migration instructions in {Install location}\shared\vnnn\pfs\Database\db2\{os}\doc
Transaction Server Scheduler XML
The following documentation describes the changes to the scheduler XML for the Transaction Server component:
- TransactionServerSchedulerChanges_v3.2.9.pdf
These documents are provided in the entitled documentation fix pack. For more information about getting this fix pack, refer to the Entitled Documentation section.
Web Services
The following documentation describes the new web services, which are implemented by using IBM WebSphere Application Server Liberty:
- IBM_FTM_Web_Services_v3.2.9.0.pdf
These documents are provided in the entitled documentation fix pack. For more information about getting this fix pack, refer to the Entitled Documentation section.
Entitled Documentation
The entitled documentation fix pack for Digital Payments can be downloaded from Fix Central by using the following link:
3.2.9-FTM-DP-MP-Documents.
General Instructions
Installation
- Start IBM Installation Manager.
- Add the location of the repository that contains the installation package:
- Select File > Preferences.
- Click Add Repository.
- Browse to the directory that contains the repository .zip file and select the file. Click Open and then OK.
- Click Test Connections and then OK.
- Click OK.
- Install the FTM product installation files to your installation directory:
- On the main pane, click Update.
- Select IBM Financial Transaction Manager for Digital Payments, IBM Financial Transaction Manager for Check Services, or IBM Financial Transaction Manager for Corporate Payment Services and then click Next.
- Select the fix pack or interim fix and then click Next.
- Follow the rest of the prompts.
- Confirm that the "Update packages" page shows success.
Deployment
- Do the database migration. Refer to the Database migration section in this document.
- Note: The runtime components can’t be running during the database migration.
- Note: Files can continue to be delivered to the Gateway inbound source folder.
- J2SE components: The installation overlays the J2SE applications, so no special migration instructions are needed. Restarting those applications updates them with the fixes.
- WebSphere Application Server components: You can use the Automated Deployment Utility (ADU), manually upgrade (refer to the update instructions in each WebSphere Application Server component doc folder), or, in a WebSphere Application Server Network Deployment configuration, use the Deployment Manager.
Note: Refer to "WebSphere Application Server 9.0.x update issue" in "Common Across Releases" > "Known Issues".- All WebSphere servers must be restarted after all the components were updated.
- For an interim fix, refer to the fix list for the modules to deploy. Note: Interim fixes are meant to be deployed on an existing WebSphere Application Server profile deployment. If you are using a new WebSphere Application Server profile and already installed the interim fix onto the prior installation, you must do two deployment passes. The first pass is to do the initial, full product deployment. The second pass is to do those components that are affected by the interim fix.
- Update your Transaction Server Scheduler.xml file. Refer to the Transaction Server Scheduler XML section in this document. Note: Updating the scheduler file might not be required for your installation.
- Refer to the release-specific section for any changes that might affect your installation.
- Start your runtime components.
- If you are using the Data Setup Utility (DSU) worksheets capability for managing your data, update your worksheets. For more information, see the Data Setup Utility section in this document.
Locate the WebSphere Application Server Liberty compressed file that is stored in the following path:
<installation directory>/ftm/vxxx/run/liberty
Where xxx = represents current FTM version that is running. For example, 329.
Decompress the file in your preferred path: <liberty-install-directory>. For example, /opt/wlp/.
Follow the following steps to create and configure the server:
1. Create your server with <liberty-install-directory>/bin/server create PFSServer.
2. Modify the server.xml.template file located in FTM installation path <installation directory>/shared/vxxx/pfs/WebServices/Liberty/PFS with config values for your install (refer to the following list of things that need to be modified).
3. Rename that file server.xml
4. Copy server.xml and jvm.options into <liberty-install-directory>/usr/servers/PFSServer.
5. Start your server with <liberty-install-directory>/bin/server start PFSServer --clean (--clean is optional).
Things that need to be modified in the server.xml.template depending on environment details:
- Db2 installation location, database name, and port.
- IBM MQ installation location, queue manager name, user, password, and port.
- The db2admin user and password.
- Set currentPackagePath, currentFunctionPath, and currentSchema to your schema name.
- Set the password for the FTM administrator ID, which is usually fxhadmin.
- WAR file deployment location: the path to the Web Services WAR file <installation directory>/shared/vxxx/pfs/WebServices/Liberty/PFS/WebServices_PFS.war.
| Back to top |
3.2.9.1 Release
|
Because the development of releases and interim fixes for maintenance are done in parallel, a later release might not contain every interim fix that was created for an earlier release. The following table shows which releases and interim fix levels can be successfully upgraded to V3.2.9.1.
In the following table, the "If you're on version" column shows you the releases that can be upgraded successfully. The latest release or interim fix level that can be upgraded for each release is shown in the "To successfully upgrade to V3.2.9.1, your version must be no higher than version" column. If the release that you are upgrading from is at an interim fix level higher than the release or fix level shown in the right column, you can't upgrade the release without losing some changes. The upgrade needs to occur at the next release.
For more information about the individual changes in a release or interim fix, see the fix list for this version.
| If you’re on version | To successfully upgrade to V3.2.9.1, your version must be no higher than version |
| 3.0.2.0 | 3.0.2.0 interim fix 2 |
| 3.0.2.1 | 3.0.2.1 interim fix 23 |
| 3.0.4.0 | 3.0.4.0 interim fix 3 |
| 3.0.4.1 | 3.0.4.1 interim fix 1 |
| 3.2.0.0 | 3.2.0.0 interim fix 1 |
| 3.2.0.1 | 3.2.0.1 interim fix 2 |
| 3.2.1.0 | 3.2.1.0 interim fix 3 |
| 3.2.2.0 | 3.2.2.0 interim fix 5 |
| 3.2.2.1 | 3.2.2.1 interim fix 3 |
| 3.2.3.0 | 3.2.3.0 interim fix 5 |
| 3.2.4.0 | 3.2.4.0 interim fix 9.1 |
| 3.2.5.0 |
3.2.5.0 interim fix 5
|
| 3.2.6.0 | 3.2.6.0 |
| 3.2.6.1 | 3.2.6.1 interim fix 5 |
| 3.2.7.0 | 3.2.7.0 interim fix 1.2 |
| 3.2.8.0 | 3.2.8.0 |
| 3.2.8.1 | 3.2.8.1 interim fix 3 |
| 3.2.9.0 | 3.2.9.0 interim fix 1 |
Known Issues
Potential issue with Cancel Request For Payment
When the Log Transaction setting on the "Request To CSM" Channel configuration is updated to Yes (Y) in FTM for Immediate Payments, the Cancel Request For Payment Web Service could fail when trying to correlate transactions. It is recommended that the Log Transaction setting for the "Request To CSM" Channel configuration remain set to No (N).
Held files might be incorrectly flagged as duplicate.
Outbound physical transmissions page might provide more restrictive results to users without entitled access
When a restrictive entitlement is configured, users must be configured to have that entitlement before they can view the entitled data. The outbound physical transmissions page incorrectly restricts the data based on the inbound data fields. So, nonentitled users have a more restrictive view of the outbound physical transmission page.
Feature changes
129041 – Creation, management, and processing of Zelle QR codes
EWS mandated that Financial Institutions that support Zelle must provide the ability to:
- Generate a QR code representing a user’s token to allow for that QR code to be scanned by others that want to send payments and payment requests to that token. (Generator of a QR code)
- Be able to retrieve Zelle recipient information from the data that is scanned from the QR code. (Consumer of QR code information)
EWS defines the QR code as:
“A visual representation of a token, which can be presented and scanned to initiate Zelle payments.”
The encoded QR code image contains the following data string:
{base URL}?data={base64 encoded(JSON object)}
The base64 encoded JSON object is this JSON structure that reflects a Zelle token and an optional “action” representing payment or request-for-payment:
{
"token": "string",
"name": "string",
"action": "enum"
}
Web service API updates
Two new Liberty web service APIs were added to support:
- QR code creation (POST /{ftm_participant_id}/token/qrcode)
The registered participant requests a QR code for one of their active tokens. FTM returns the QR code image as a Base64 encoded string as well as the encoded data string that is embedded in the provided image. This web service is used when a participant wants to provide their QR code to another person for that person to send the participant a Zelle payment.
- QR code processing (POST /{ftm_participant_id}/recipient/qrcode)
The registered participant requests recipient data for the encoded data that was scanned, extracted from a QR code. FTM decodes the scanned data and calls EWS’ GetTokenStatus web service to gather specifics about the recipient. The web service returns the scanned QR code data (the decoded JSON), the EWS specifics about the recipient, and the stored recipient first name, last name (nickname known to the participant), if available. It is assumed that the FI’s mobile app will use this data to enter the payment, payment request workflow depending on the data that is returned.
More specific details about these web services, including YAML files and workflow diagrams, are included in the entitled documents.
WebSphere Application Server Liberty updates
If the sample server.xml is not used, an additional Liberty feature is required and needs to be included within the <featureManager> section of the server.xml. The new feature is:
<feature>jaxws-2.2</feature>
This feature allows direct SOAP calls from the Liberty server to EWS.
ibm-ws-bnd.xml
A new WEB-INF/ibm-ws-bnd.xml file is deployed in the WebServices_Zelle.war. Edit this file to properly configure EWS connectivity for the application running on the Liberty server. Details about using/configuring this file can be found in the WebSphere Application Server Liberty documentation here:
https://www.ibm.com/docs/en/was-liberty/nd?topic=liberty-ws-bndxml-file
130801 – Handle “Accept Without Posting” payment status on originated Zelle payments
EWS mandated that Financial Institutions that receive real-time Zelle payments can update the status of the payment to “Accept without Posting” to indicate that the “Receiving Organization cannot definitively post a real-time payment to the recipient’s account”. The originator of the payment will be notified of the new ”Accept without Posting” (AWP) status via the OnPaymentStatusChange notification.
FTM will now handle the AWP payment status on originated real-time Zelle payments.
The supported version of the OnPaymentStatusChange notification is now version 4.3 to allow for integration of the AWP status. This new version of the notification will include the AWP reason code field (legal-regulatory, fraud-risk, dn-uncertain) when the status is AWP. It will also include a “government impounded” Boolean flag when the status is Delivered.
When the Originating FI receives the AWP status:
- A notification should be sent to the sender that the payment is delayed.
- Funds were transferred from the sender’s account, but the originated payment is not available for ACH distribution
- Payments in AWP should be rolled over just like payments in pending acceptance status (AWP status will be included in FTM rollover logic)
- The originated payment cannot be cancelled (by the originator/originating org).
When the Receiving FI Fails/Denies a payment that was AWP, the Originating FI will (current Failed/Denied processing):
- Reverse the funds to the sender
- Notify the sender that the payment was Failed/Denied
When the Receiving FI Delivers a payment that was AWP, the Originating FI will:
- Distribute the ACH settlement for the payment
- Notify the sender that the payment was Delivered (after being previously delayed). The notification must contain additional verbiage if the delivered payment was flagged as “government impounded”.
UI page updates
- Transaction pages were updated to correctly render and display the new “Accept without Posting” Zelle payment status.
- Originated Zelle payments in AWP will not be allowed to be cancelled.
- The Zelle tab on the transaction details screen will include the AWP reason code and Government Impounded flag (when available).
Web service API updates
All current web services that read CXCPayment details were updated to include the new AWP status, the AWP reason code, and the Government impounded flag (when available).
Notification User Exit updates
The existing “sendPaymentDelayed” UX method will be called whenever the AWP status is received for an originated Zelle payment. The CXCPayment object passed to that UX method will contain the new AWP status as well as AWP reason code. The FI’s implementation of that method will be able to determine why the payment has been delayed and decision any text changes that are required.
A new “delayedPaymentDelivered” UX method is added to support the AWP status. This method will be called when a payment that was previously AWP has now been set to Delivered by the Receiving FI. The new method will be passed a CXCPayment object. That object will reflect whether it was marked as “Government impounded” and the FI’s implementation will be able to update notification text based on the information from the payment object.
Migration
- DSUmigration_v3.2.9.pdf
- DSUMigrationBR_v3.2.9.pdf
These documents are provided in the entitled documentation fix pack. The entitled documentation fix pack for Digital Payments can be downloaded from Fix Central by using the following link:
3.2.9-FTM-DP-MP-Documents.
| Back to top |
3.2.9.0 interim fix 9
|
None.
None.
None.
| Back to top |
3.2.9.0 interim fix 8
|
None.
None.
None.
| Back to top |
3.2.9.0 interim fix 7
|
None.
None.
None.
| Back to top |
3.2.9.0 interim fix 6
|
None.
None.
None.
| Back to top |
3.2.9.0 interim fix 5
|
Please note that Immediate Payments 3.2.9.0 interim fix 2 is required for this release of Digital Payments.
None.
None.
| Back to top |
3.2.9.0 interim fix 4.1
|
- Call WS API to do an ONUS Initiate Credit Transfer (pain.001).
- Perform 'Request Return of Funds' through Digital Payments UI 'Inbound Transactions' by selecting the pain.001 transaction and then More->Actions->'Request Return of Funds'
- Perform 'Accept and Return through Digital Payments UI by selecting the transaction with message type camt.056 and Status 'Wait for Resolution of Investigation'
- DSU change in Samples. Add to SampleAchConfiguration.xlsx, worksheet 'Transmission Msg Type Configs' one row: TCH Single Origination Ret Int INTERNAL_TCH S_TxnDistributionCreated INTERNAL IP_FROM_CDTR_RET
- Run the Db2 command: INSERT INTO TRANS_DEF_MSG_TYPE_CONFIG (FILE_DEF_ID , MESSAGE_TYPE_ID , TXN_STATE_1 , TXN_CLASS , TXN_SUBTYPE , CREATED, LAST_MODIFIED , CREATED_BY , MODIFIED_BY ) VALUES (28, 1420, 'S_TxnDistributionCreated', 'INTERNAL', 'IP_FROM_CDTR_RET', '2022-05-31-15.49.56.786000', '2022-05-31-15.49.56.786000', 'db2admin', null)
- From the Digital Payments UI Configuration->Outbound->Transmission Msg Type Configs page, create a new transmission that has the following fields: TCH Single Origination Ret Int, INTERNAL_TCH, S_TxnDistributionCreated, INTERNAL, IP_FROM_CDTR_RET
Zelle Payments/Ids over TCH RTP
Pain.001 Payment API
Generally, the rules for the pain.001 API are the same as for the Channel/MQ pacs.008.
- LclInstrm set to proprietary code ZELLE
- CstmrCdtTrfInitn/GrpHdr/CreDtTm (passed as-is from channel)
- CstmrCdtTrfInitn/GrpHdr/MsgId (1-24 passed as-is from channel, last 11 replaced)
- CstmrCdtTrfInitn/CdtTrfTxInf/PmtId/InstrId (passed as-is from channel)
However, the main exception is TxId. The pain.001 does not natively support a TxId and a pain.001 API call that wants to use a different TxId (different to InstrId) must provide that value in the Supplementary Data fields of the PmtId.
<CdtTrfTxInf>
<PmtId>
. . .
</PmtId>
. . .
<SplmtryData>
<PlcAndNm>CdtTrfTxInf/PmtId</PlcAndNm> <!-- Indicates that it extends the parent CdtTrfTxInf/PmtId data -->
<Envlp>
<!-- Only needed for response to Zelle RFP -->
<!-- Preformatted Zelle/TCH TxId:
YYYYMMDD
+ Participant ID (11)
+ Message generation source (“B” if generated by Participant)
+ Message serial identifier (2 digits)
+ Zelle Payment Request ID(13 digits)
The example value might not be fully valid!
-->
<TxId>2022050400123456780BP2PFGB123456789</TxId>
</Envlp>
</SplmtryData>
</CdtTrfTxInf>
None.
| Back to top |
3.2.9.0 interim fix 4
|
134752
Use the following file to insert values:
3.2.9.0_ifix4_OTW_134752.ddl
It can be downloaded from Fix Central at 3.2.9-FTM-DP-MP-Documents.
None.
None.
| Back to top |
3.2.9.0 interim fix 3
|
133468
Here are the instructions:
WebSphere enterprise Applications -> check box next to FrameworkUI_EAR
Select Update.
Select Replace, Add, or Delete multiple files.
Select Choose path:
Find the location of the install.
Go to the FrameworkUI folder -> v329\pfs\FrameworkUI\console\frameworkui\lib\FrameworkUI_EAR_Update
Select Next.
Select Ok.
Select Save.
None.
None.
| Back to top |
3.2.9.0 interim fix 2
|
None.
127300
The customer acknowledgment (pacs.002) is missing when Digital Payments fails to notify Immediate Payments to process the Initiate Credit Transfer or Initiate Request for Payment.
- Create Initiate Credit Transfer V1 (Web Services API).
- Create Initiate Request for Payment V1 (Web Services API).
- Create Initiate Request for Payment V2 (Liberty Web Services API).
If Digital Payment's distribution notification is received after timeout, the Immediate Payment continues processing as normally. So, it’s possible that the client may receive the pacs.002 indicating a timeout reject, then successful pacs.002 after Immediate Payment sends the pain.001 or pain.013 to TCH.
None.
| Back to top |
3.2.9.0 Release
|
Because the development of releases and interim fixes for maintenance are done in parallel, a later release might not contain every interim fix that was created for an earlier release. The following table shows which releases and interim fix levels can be successfully upgraded to V3.2.9.0.
In the following table, the "If you're on version" column shows you the releases that can be upgraded successfully. The latest release or interim fix level that can be upgraded for each release is shown in the "To successfully upgrade to V3.2.9.0, your version must be no higher than version" column. If the release that you are upgrading from is at an interim fix level higher than the release or fix level shown in the right column, you can't upgrade the release without losing some changes. The upgrade needs to occur at the next release.
For more information about the individual changes in a release or interim fix, see the fix list for this version.
| If you’re on version | To successfully upgrade to V3.2.9.0, your version must be no higher than version |
| 3.0.2.0 | 3.0.2.0 interim fix 2 |
| 3.0.2.1 | 3.0.2.1 interim fix 23 |
| 3.0.4.0 | 3.0.4.0 interim fix 3 |
| 3.0.4.1 | 3.0.4.1 interim fix 1 |
| 3.2.0.0 | 3.2.0.0 interim fix 1 |
| 3.2.0.1 | 3.2.0.1 interim fix 2 |
| 3.2.1.0 | 3.2.1.0 interim fix 3 |
| 3.2.2.0 | 3.2.2.0 interim fix 5 |
| 3.2.2.1 | 3.2.2.1 interim fix 3 |
| 3.2.3.0 | 3.2.3.0 interim fix 5 |
| 3.2.4.0 | 3.2.4.0 interim fix 9.1 |
| 3.2.5.0 |
3.2.5.0 interim fix 4
|
| 3.2.6.0 | 3.2.6.0 |
| 3.2.6.1 | 3.2.6.1 interim fix 5 |
| 3.2.7.0 | 3.2.7.0 interim fix 1.1 |
| 3.2.8.0 | 3.2.8.0 |
| 3.2.8.1 | 3.2.8.1 interim fix 1 |
Known Issues
Potential issue with Cancel Request For Payment
When the Log Transaction setting on the "Request To CSM" Channel configuration is updated to Yes (Y) in FTM for Immediate Payments, the Cancel Request For Payment Web Service could fail when trying to correlate transactions. It is recommended that the Log Transaction setting for the "Request To CSM" Channel configuration remain set to No (N).
Held files might be incorrectly flagged as duplicate.
Outbound physical transmissions page might provide more restrictive results to users without entitled access
When a restrictive entitlement is configured, users must be configured to have that entitlement before they can view the entitled data. The outbound physical transmissions page incorrectly restricts the data based on the inbound data fields. So, nonentitled users have a more restrictive view of the outbound physical transmission page.
Feature changes
49844
The NACHA Edits DSU configurations were updated to reflect the supported 2021 NACHA Guidelines (from 2017/2016). All installs should now support Business Rules Validation NACHA 2021 and no longer support Business Rules Validation NACHA 2017 or 2016.
77318
Response to Request for Information (camt.028)
A new Response to Request For Information web service was created. For more information, refer to the openapi-transactions-3.2.9.yaml that is included in the entitled documentation.
Usage
Post http://localhost:57107/transactions/responsetorfi
Asynchronous mode example
Request
POST http://localhost:57107/transactions/responsetorfi HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: zzz
x-ftm-audit-host: aaa
Content-Length: 363
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": true,
"ftm_transaction_id": 142826,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"initiator_type": "Customer",
"ustrd": [
"aaa", "bbb", "ccc", "ddd"
],
"timeout": 8000
}
Response
{
"reason_code": "Customer",
"response_status_report": [{"request_information_and_status": {
"ftm_transaction_id": 142826,
"ftm_transaction_status": "Request For Information Complete"
}}],
"timeout": false
}
Synchronous mode example
Request
POST http://localhost:57107/transactions/responsetorfi HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: zzz
x-ftm-audit-host: aaa
Content-Length: 364
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": false,
"ftm_transaction_id": 142826,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"initiator_type": "Customer",
"ustrd": [
"aaa", "bbb", "ccc", "ddd"
],
"timeout": 8000
}
Response
{
"reason_code": "Customer",
"response_status_report": [ {
"request_information_and_status": {
"ftm_transaction_id": 142826,
"ftm_transaction_status": "Request For Information Complete"
},
"response_information_and_status": {
"ftm_transaction_id": 21028,
"ftm_transaction_status": "Request For Information Response Complete",
"ftm_transmission_id": 141018
}
}],
"timeout": false
}
119500
Two new optional parameters were added to four of the Transaction Services web services. These two parameters are application name and web service ID. These two parameters if present will be added as extended values to the transactions.
The Web Service ID, if used, should be a unique ID that the caller can use to identify the transaction being created by the web service. The PFSServer get transactions web service can be used to get the transaction associated with the web service ID.
The application name is currently only use to identify the application that called the web service.
The PFSTransactionServer web services that use the new fields are:
initiateCreditTransfer
paymentAcknowledgment
remittanceAdvice
RespondtoRFI
In later releases, more web services will support these optional fields.
119503
Cancel a Request for Payment (camt.056)
A new Cancel Request for Payment web service was created. For more information, refer to the openapi-transactions-3.2.9.yaml that is included in the entitled documentation.
Usage
POST http://localhost:57107/transactions/cancelrequestforpayment
Asynchronous mode example
Request
POST http://localhost:57107/transactions/cancelrequestforpayment HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json;charset=UTF-8
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 358
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": true,
"ftm_transaction_id": 19014,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"reason_code": "CUST",
"additional_info": "some info",
"timeout": 8000
}
Response
{
"action": "Expiry",
"reason_code": "CUST",
"response_status_report": [{"request_information_and_status": {
"ftm_transaction_id": 19014,
"ftm_transaction_status": "Wait for Request for Payment Response",
"ftm_transmission_id": 19013
}}],
"timeout": false
}
Synchronous mode example
Request
POST http://localhost:57107/transactions/cancelrequestforpayment HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json;charset=UTF-8
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 359
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": false,
"ftm_transaction_id": 10090,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"reason_code": "CUST",
"additional_info": "some info",
"timeout": 8000
}
Response
{
"action": "Expiry",
"reason_code": "CUST",
"response_status_report": [ {
"request_information_and_status": {
"ftm_transaction_id": 10090,
"ftm_transaction_status": "Wait for Request for Payment Response",
"ftm_transmission_id": 10089
},
"response_information_and_status": {
"ftm_transaction_id": 17023,
"ftm_transaction_status": "Outgoing Request for Payment Cancel Complete",
"ftm_transmission_id": 23004
}
}],
"timeout": false
}
119592
Payment acknowledgment (camt.035)
A new payment acknowledgment web service was created. For more information, refer to the openapi-transactions-3.2.9.yaml that is included in the entitled documentation.
Usage
POST http://localhost:57107/transactions/paymentacknowledgment
Asynchronous mode example
Request
POST http://localhost:57107/transactions/paymentacknowledgment HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 358
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": true,
"ftm_transaction_id": 17002,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"initiator_type": "Customer",
"additional_info": null,
"timeout": 8000
}
Response
{
"action": "ACK",
"reason_code": "Customer",
"response_status_report": [{"request_information_and_status": {
"ftm_batch_id": 17001,
"ftm_transaction_id": 17002,
"ftm_transaction_status": "Credit Transfer Complete",
"ftm_transmission_id": 17000
}}],
"timeout": false
}
Synchronous mode example
Request
POST http://localhost:57107/transactions/paymentacknowledgment HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 359
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": false,
"ftm_transaction_id": 19002,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"initiator_type": "Customer",
"additional_info": null,
"timeout": 8000
}
Response
{
"action": "ACK",
"reason_code": "Customer",
"response_status_report": [ {
"request_information_and_status": {
"ftm_batch_id": 19001,
"ftm_transaction_id": 19002,
"ftm_transaction_status": "Credit Transfer Complete",
"ftm_transmission_id": 19000
},
"response_information_and_status": {
"ftm_transaction_id": 23000,
"ftm_transaction_status": "Payment Acknowledgment Complete",
"ftm_transmission_id": 10009
}
}],
"timeout": false
}
119594
Remittance Advice (remt.001)
A new Remittance Advice web service was created. For more information, refer to the openapi-transactions-3.2.9.yaml that is included in the entitled documentation.
Usage
POST http://localhost:57107/transactions/remittanceadvice
Asynchronous mode example
Request
POST http://localhost:57107/transactions/remittanceadvice HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 971
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": true,
"ftm_transaction_id": 29002,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"rmt_advc": "<RmtAdvc><GrpHdr><MsgId>M2021101902001000099BFFF00000000032</MsgId><CreDtTm>2021-10-19T03:04:30</CreDtTm><InitgPty><Id><OrgId><Othr><Id>123456780</Id></Othr></OrgId></Id></InitgPty><MsgRcpt><Id><OrgId><Othr><Id>987654320</Id></Othr></OrgId></Id></MsgRcpt></GrpHdr><RmtInf><RmtId>20211019INFOABCD00000000031</RmtId><OrgnlPmtInf><Refs><InstrId>2021101902001000099BFFFF00000000031</InstrId><EndToEndId>E2E-TxPrefix20160513223041391000000</EndToEndId><TxId>2021101902001000099BFFFF00000000031</TxId></Refs><Amt><InstdAmt Ccy=\"USD\">321.98</InstdAmt></Amt><CdtrAcct><Id><Othr><Id>12000194212199001</Id></Othr></Id></CdtrAcct></OrgnlPmtInf></RmtInf></RmtAdvc>",
"timeout": 8000
}
Response
{
"response_status_report": [{"request_information_and_status": {
"ftm_batch_id": 29001,
"ftm_transaction_id": 29002,
"ftm_transaction_status": "Credit Transfer Complete",
"ftm_transmission_id": 29000
}}],
"timeout": false
}
Synchronous mode example
Request
POST http://localhost:57107/transactions/remittanceadvice HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 972
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": false,
"ftm_transaction_id": 29005,
"appl_name": "xxxxxx",
"ws_id": 2021081715553000000000002,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"rmt_advc": "<RmtAdvc><GrpHdr><MsgId>M2021101902001000099BFFF00000000032</MsgId><CreDtTm>2021-10-19T03:04:30</CreDtTm><InitgPty><Id><OrgId><Othr><Id>123456780</Id></Othr></OrgId></Id></InitgPty><MsgRcpt><Id><OrgId><Othr><Id>987654320</Id></Othr></OrgId></Id></MsgRcpt></GrpHdr><RmtInf><RmtId>20211019INFOABCD00000000031</RmtId><OrgnlPmtInf><Refs><InstrId>2021101902001000099BFFFF00000000031</InstrId><EndToEndId>E2E-TxPrefix20160513223041391000000</EndToEndId><TxId>2021101902001000099BFFFF00000000031</TxId></Refs><Amt><InstdAmt Ccy=\"USD\">321.98</InstdAmt></Amt><CdtrAcct><Id><Othr><Id>12000194212199001</Id></Othr></Id></CdtrAcct></OrgnlPmtInf></RmtInf></RmtAdvc>",
"timeout": 8000
}
Response
{
"response_status_report": [ {
"request_information_and_status": {
"ftm_batch_id": 29004,
"ftm_transaction_id": 29005,
"ftm_transaction_status": "Credit Transfer Complete",
"ftm_transmission_id": 29003
},
"response_information_and_status": {
"ftm_transaction_id": 25044,
"ftm_transaction_status": "Outgoing Remittance Advice Complete",
"ftm_transmission_id": 10020
}
}],
"timeout": false
}
122195
When running Java applications in a time zone that adheres to Daylight Saving Time (EST for example), the conversion between EST to UTC will always have a "gap" during the 5-hour window of Daylight Saving Time switch over on the night that Daylight Saving Time occurs. The conversions within the JVM will always have inconsistent results when that switchover occurs.
To alleviate this issue, it is recommended that all J2SE applications should run in UTC.
The J2SE Applications (Business Rules Server, Distribution Manager, Gateway Server, and Transaction Server) startup scripts were updated to run under UTC time zone by default.
The "-Duser.timezone=UTC" JVM option should be added to all J2SE application startups if not replaced with "out of the box" startup scripts. Console output for the J2SE applications will show UTC timestamps instead of timestamps in the local time zone.
All DSU, Transaction Server scheduler, etc. configuration should still reflect the operational time zone that is wanted by the FI. There should be no requirement to perform any time zone "math" to adjust any configuration to UTC. Updates were made to accommodate those conversions within the applications.
122387
Updates were made to FTM's sample Business Rules configuration so that same day endpoint assignments are made on a $1 million limit after 3/18/2022. With the change, same day endpoint assignments before 3/18/2022 still reflect the current $100K same day limit.
122881
The WebSphere Liberty server was upgraded to 21.0.0.6.
The following list shows the server versions and JARs as a result of the upgrade.
wlp-base-all-21.0.0.6.jar
wlp-base-embeddable-21.0.0.6.zip
com.ibm.websphere.appserver.api.basics_1.4.53.jar
com.ibm.websphere.appserver.api.kernel.service_1.0.53.jar
com.ibm.websphere.appserver.api.security_1.3.53.jar
com.ibm.websphere.appserver.api.ssl_1.4.53.jar
com.ibm.websphere.javaee.jsp.tld.2.2_1.2.53.jar
123124
A new return transaction type column was added to the return reason codes xref database table that reflects the type of transaction that the return reason code applies to. The new column has a default of ALL transaction types. The value of the new column is defined per return message standard.
When a single transaction is returned, the reason code selection includes return reasons that are configured to be for All transaction types and the return codes that are configured to be for that specific transaction type. The potential transaction types are credit and debit. In the return reason codes xref database table, the new return transaction type has 'C' for Credit, 'D' for Debit, and 'A' for all.
When multiple transactions are returned, if the transactions have the same transaction type, the same rules as a single transaction apply. If the selected transactions have the different transaction types, the reason code selection includes All return reasons including debit and credit only. If a debit or credit only reason code is selected, the reason code validation on the dialog highlights that the reason code selected is not valid for all the transaction types selected.
123508
Entitlements support
Starting with v3.2.9.0, FTM supports entitlement configuration by using the Control Center user interface. Entitlements are a way to enforce restrictions/entitlements on users and groups. Based on the configuration, entitlements can restrict/enable users from seeing certain sensitive data on user interface pages. For 3.2.9.0, the following features were added:
- Entitlement configuration is now available from Control Center user interface.
- Configuration pages can be accessed from the main menu: Administration -> Security -> Entitlements.
- Configuration only supports "Global UI Runtime Grid" for Resource value, which applies the entitlements globally across the following payment data user interface pages.
- Inbound: Physical Transmissions, Transmissions, Batches, Processing Batches, and Transactions
- Outbound: Physical Transmissions, Transmissions, and Batches.
- Entitlement Condition configuration only supports "Global Bank Id" for Criteria value, which will apply to the following columns on the user interface pages:
- Inbound: Sender ID, Processor ID and Sender Alias, Processor Alias (where available).
- Outbound Physical Transmissions: Sender ID, Processor ID
- Outbound: Receiver
- Entitlement Condition configuration only supports "Equals" and "Not Equals" for Operator values.
- Entitlements can be assigned to a group by using the new action icon on the Groups page.
User interface screen captures
Entitlements:
Entitlement Conditions
To get to Entitlement Conditions page, click the “Manage Conditions” button on the top of the Entitlements Grid.
Group Entitlement Assignments dialog
Permissions
Permissions for Entitlement pages, including the Entitlement Condition pages, can be configured as shown in the following figure:
The new Entitlement assignment action on the groups grid, to assign an Entitlement to a group, has separate permissions and can be configured as shown in the following figure:
124496
FTM was upgraded to the 4.3 EWS WSDL for Zelle processing. No API changes or upgrades are related to this new WSDL within the FTM product. The upgrade to the new version of EWS is to allow for possible future enhancements without the required WSDL version upgrade.
124723
Send payments/payment requests to a Zelle tag
EWS has mandated that participants should be able to send payments and payment requests to “Zelle Tag” tokens by April 2022. Zelle Tag tokens are a new type of token being added/supported by EWS.
FTM is being updated so that payments and payment requests can be sent to Zelle recipients that have a registered Zelle tag token. This process will be identical to sending transactions to mobile and email Zelle tokens.
Also, users will be able to add Zelle Tag token recipients (like mobile and email tokens) to their Zelle recipients.
The updated APIs specific to Zelle Tag support are documented in the entitled documentation.
125245
The customization for the ISO20022 message types to ISF conversion process was enabled.
The current supported message type is pain.001 and pain.013 only.
125618
The intitateCreditTransfer API version 2 (ICT-v2, Liberty-based web service) is used for real-time payments (retail transactions) as well as batch transactions. The real-time transaction will have the caller waiting for the transaction to complete, while the batch transactions will not. For this reason, the real-time transactions should have priority over the batch transactions.
Three new optional fields were added to its signature: calling application name (appl_name), webServiceId (ws_id) and priority (between 0 the lowest and 100 the highest).
Example:
{
"asynchronous": false,
"audit_source": "The source for the audit info",
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing.",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"outbound_message_type": "pain.001",
"processing_bank_code": "123456780",
"credit_transfer": "<pain.001>",
"ref_transaction_id": null,
"ref_payment_id": null,
"appl_name": "abcdefg",
"ws_id": "2021081715553000000000002",
"priority": 51,
"timeout": 8000
}
In this way the real-time payments will be routed to an endpoint associated with a high priority channel and batch transactions will be routed to an endpoint associated with a low-priority channel.
The messages passed between PFSTransactions, Transaction Server and Gateway will be inserted to the corresponding message queues using the priority of the ICT-v2 request.
The three new fields in the web service call are loaded to the database. The calling application name is added to the obj_value table, webServiceId is added to the ID_REFERENCE table and priority is stored in the obj_base table in the TECH_PRIORITY column.
Logic must be added to the PaymentMethodOut Node to test if the ibmNprEndpoint assigned is TCHORIG and the ibmNprMessagePriority is less than 6 (for example) then the endpoint will be changed to TCHBATCH. If the ibmNprMessagePriority is null then no change is made. Details in DSUMigrationBR_v3.2.9 release notes.
125847
Zelle Reminder notification for senders with unknown payments about to expire
The Zelle User Experience Guide is being updated to change the optionality of the use case: “Payment Sent to Unknown Recipient, Reminder(s) - Notify Sender” to a mandatory use case. The modification to this use case notification is intended to aid in reducing expired Payments by notifying the Sender to contact the Unknown Recipient to remind them to enroll in Zelle in order for the Unknown Recipient to receive the Payment.
Two new Zelle notification API methods have been added to the Zelle notification interface:
- public void sendExpirationReminder(CXCPayment cxcPayment)
- public void sendExpirationReminder(CXCPaymentRequest cxcPaymentRequest)
The FI can implement the details of these methods in order to send a proper upcoming expiration reminder to the originator of the transactions.
The CXCExpirePaymentsTask has been updated to include an optional parameter for “Notification reminder days prior to expiration”:
When the “Notification reminder days prior to expiration” parameter is set, the expiration task will determine which transactions (Payment or Payment Request) are within the configured interval. For those transactions, the task will call the above notification UX methods to allow the correct expiration reminder to be sent.
127056
Initiate Credit Transfer V2
A new version (V2) of the Initiate Credit Transfer web service was created. The existing web service API was marked as deprecated. For more information, refer to the openapi-transactions-3.2.9.yaml that is included in the entitled documentation.
V1 versus V2
Initiate Credit Transfer V1 is using the traditional WebSphere Application Server, for example, on a local install:
http://localhost:58080/ws/svc/initiatecredittransfer
Initiate Credit Transfer V1 is being deprecated.
Initiate Credit Transfer V2 is using WebSphere Application Server Liberty and Digital Payments FTM:
http://localhost:57107/transactions/initiatecredittransfer_v2
While V1 and V2 use the same content for the request payload and the response, V1 is using the camel case while V2 is using the snake case naming convention.
Initiate Credit Transfer V2 is using 3 new optional fields: priority, appl_name, ws_id.
Usage
POST http://localhost:57107/transactions/initiatecredittransfer_v2
Synchronous mode example
Request
POST http://localhost:57107/transactions/initiatecredittransfer_v2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: The source for the audit info
x-ftm-audit-host: 10.22.108.433
Content-Length: 3060
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"asynchronous": false,
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing.",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"outbound_message_type": "pain.001",
"processing_bank_code": "123456780",
"credit_transfer": "<?xml version=\"1.0\" encoding=\"UTF-8\"?><Document xmlns=\"urn:iso:std:iso:20022:tech:xsd:pain.001.001.09\"><CstmrCdtTrfInitn><GrpHdr><MsgId>1234567890123456789012345678901234</MsgId><CreDtTm>2019-06-05T07:07:00</CreDtTm><NbOfTxs>1</NbOfTxs><CtrlSum>109</CtrlSum><InitgPty><Nm>ABC Corporation</Nm><PstlAdr><StrtNm>Times Square</StrtNm><BldgNb>7</BldgNb><PstCd>NY 10036</PstCd><TwnNm>New York</TwnNm><Ctry>US</Ctry></PstlAdr><Id><OrgId><Othr><Id>123456780</Id><SchmeNm><Prtry>Value</Prtry></SchmeNm></Othr></OrgId></Id></InitgPty></GrpHdr><PmtInf><PmtInfId>Chan_PmtInfId__00000109</PmtInfId><PmtMtd>TRF</PmtMtd><PmtTpInf><SvcLvl><Cd>SDVA</Cd></SvcLvl><LclInstrm><Prtry>STANDARD</Prtry></LclInstrm><CtgyPurp><Prtry>CONSUMER</Prtry></CtgyPurp></PmtTpInf><ReqdExctnDt><Dt>2019-06-05</Dt></ReqdExctnDt><Dbtr><Nm>Moon River</Nm><PstlAdr><StrtNm>Times Square</StrtNm><BldgNb>7</BldgNb><PstCd>NY 10036</PstCd><TwnNm>New York</TwnNm><CtrySubDvsn>NW236373</CtrySubDvsn><Ctry>US</Ctry><AdrLine>2199 JW Clay Blvd</AdrLine></PstlAdr><Id><OrgId><LEI>A1113456091873457293</LEI></OrgId></Id></Dbtr><DbtrAcct><Id><Othr><Id>1200019421210007</Id></Othr></Id><Prxy><Id>P9828282</Id></Prxy></DbtrAcct><DbtrAgt><FinInstnId><ClrSysMmbId><MmbId>123456780</MmbId></ClrSysMmbId></FinInstnId></DbtrAgt><UltmtDbtr><Nm>Chandler Bing</Nm><PstlAdr><StrtNm>Senator Royall Drive</StrtNm><BldgNb>2109</BldgNb><PstCd>28262</PstCd><TwnNm>Charlotte</TwnNm><CtrySubDvsn>147</CtrySubDvsn><Ctry>US</Ctry><AdrLine>2109 Summertime Drive</AdrLine></PstlAdr><Id><OrgId><LEI>A1113456091873457567</LEI></OrgId></Id></UltmtDbtr><CdtTrfTxInf><PmtId><InstrId>Chan_InstrId__00000109</InstrId><EndToEndId>Chan_E2E__00000109</EndToEndId></PmtId><Amt><InstdAmt Ccy=\"USD\">109</InstdAmt></Amt><ChrgBr>SLEV</ChrgBr><CdtrAgt><FinInstnId><ClrSysMmbId><MmbId>987654320</MmbId></ClrSysMmbId></FinInstnId></CdtrAgt><Cdtr><Nm>DEF Electronics</Nm><PstlAdr><StrtNm>Mark Lane</StrtNm><BldgNb>55</BldgNb><PstCd>EC3R7NE</PstCd><TwnNm>London</TwnNm><CtrySubDvsn>87RT</CtrySubDvsn><Ctry>GB</Ctry><AdrLine>9872 Univ Blvd.</AdrLine></PstlAdr><Id><OrgId><LEI>A1113456091873457568</LEI></OrgId></Id></Cdtr><CdtrAcct><Id><Othr><Id>12000194212188888</Id></Othr></Id><Prxy><Id>5656565656</Id></Prxy></CdtrAcct><InstrForDbtrAgt>ChanRef:abc123459</InstrForDbtrAgt><Purp><Cd>GDDS</Cd></Purp><RltdRmtInf><RmtId>2020013116264838R008txuc4_rmt_good.</RmtId></RltdRmtInf><RmtInf><Strd><RfrdDocInf><Tp><CdOrPrtry><Cd>CINV</Cd></CdOrPrtry></Tp><Nb>4562</Nb><RltdDt>2006-09-08</RltdDt></RfrdDocInf></Strd></RmtInf></CdtTrfTxInf></PmtInf></CstmrCdtTrfInitn></Document>",
"ref_transaction_id": null,
"ref_payment_id": null,
"appl_name": "abcdefg",
"ws_id": "2021081715553000000000002",
"priority": 51,
"timeout": 8000,
"validate_schema": true
}
Response
[{
"amount": 109,
"batch_id": 141021,
"creditor_name": "DEF Electronics",
"debtor_name": "Moon River",
"original_create_date_time": "2019-06-05T07:07:00",
"original_message_identification": "1234567890123456789012345678901234",
"payment_status_information": "COMPLETE",
"timeout": false,
"transaction_id": 141022,
"transaction_status": {
"cid": "Chan_InstrId__00000109",
"ftm_transaction_status": "ACTC",
"payment_id": {
"identifier": 1,
"int_identifier": 0,
"type": 6,
"descriptor": "PMTID"
},
"pres_status": "Complete",
"presentment_group_id": {
"identifier": 1,
"int_identifier": 0,
"type": 1,
"descriptor": "PRGRPID"
},
"presentment_id": {
"identifier": 2,
"int_identifier": 0,
"type": 2,
"descriptor": "PRESID"
},
"received": "2021-12-03T00:51:22.189Z[UTC]",
"txn_status": "Accepted",
"uid": "Chan_InstrId__00000109",
"validation_count": 0,
"validation_results": []
},
"transmission_id": 141020
}]
Asynchronous mode example
Request
{
"asynchronous": true,
"audit_source": "The source for the audit info",
"comment_and_contact": {
"comment": "The user-defined comment that is used for auditing.",
"contact_name": "John Doe",
"contact_phone": "13424454224"
},
"outbound_message_type": "pain.001",
"processing_bank_code": "123456780",
"credit_transfer": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!-- \n Licensed materials - Property of IBM\n\n 5655-FIN 5655-Y11\n 5724-D96 5725-F79\n\n (C) Copyright IBM Corp. 2011, 2012\n-->\n\n<Document xmlns=\"urn:iso:std:iso:20022:tech:xsd:pain.001.001.09\">\n<CstmrCdtTrfInitn>\n<GrpHdr>\n<MsgId>Chan_MsgId__00000109</MsgId>\n<CreDtTm>2019-06-05T07:07:00</CreDtTm>\n<NbOfTxs>1</NbOfTxs>\n<CtrlSum>109</CtrlSum>\n<InitgPty>\n<Nm>ABC Corporation</Nm>\n<PstlAdr>\n<StrtNm>Times Square</StrtNm>\n<BldgNb>7</BldgNb>\n<PstCd>NY 10036</PstCd>\n<TwnNm>New York</TwnNm>\n<Ctry>US</Ctry>\n</PstlAdr>\n<Id>\n<OrgId>\n<Othr>\n<Id>123456780</Id>\n<SchmeNm>\n<Prtry>Value</Prtry>\n-- <Cd>pain</Cd> -->\n</SchmeNm>\n</Othr>\n</OrgId>\n</Id>\n</InitgPty>\n</GrpHdr>\n<PmtInf>\n<PmtInfId>Chan_PmtInfId__00000109</PmtInfId>\n<PmtMtd>TRF</PmtMtd>\n<PmtTpInf>\n<SvcLvl>\n<Cd>SDVA</Cd>\n</SvcLvl>\n<LclInstrm>\n<Prtry>STANDARD</Prtry>\n</LclInstrm>\n<CtgyPurp>\n<Prtry>CONSUMER</Prtry>\n</CtgyPurp>\n</PmtTpInf>\t\t\t\n<ReqdExctnDt>\n<Dt>2019-06-05</Dt>\n</ReqdExctnDt>\n<XpryDt>\n<Dt>2099-12-31</Dt>\n</XpryDt>\n<Dbtr>\n<Nm>Moon River</Nm>\n<PstlAdr>\n<StrtNm>Times Square</StrtNm>\n<BldgNb>7</BldgNb>\n<PstCd>NY 10036</PstCd>\n<TwnNm>New York</TwnNm>\n<CtrySubDvsn>NW236373</CtrySubDvsn>\n<Ctry>US</Ctry>\n<AdrLine>2199 JW Clay Blvd</AdrLine>\n</PstlAdr>\n<Id>\n<OrgId>\n<LEI>A1113456091873457293</LEI>\n</OrgId>\n<!-- <PrvtId>\n\t<DtAndPlcOfBirth>\n\t<BirthDt>1969-06-28</BirthDt>\n\t<CityOfBirth>City</CityOfBirth>\n\t<CtryOfBirth>US</CtryOfBirth>\n\t</DtAndPlcOfBirth>\n\t<Othr>\n\t<Id>9230012</Id>\n\t<SchmeNm>\n\t<Cd>CUST</Cd>\n\t</SchmeNm>\n\t<Issr>Bank</Issr>\n\t</Othr>\n</PrvtId> -->\n</Id>\n</Dbtr>\n<DbtrAcct>\n<Id>\n<Othr><Id>1200019421210007</Id></Othr>\n</Id>\n<Prxy>\n<Id>P9828282</Id>\n</Prxy>\n</DbtrAcct>\n<DbtrAgt>\n<FinInstnId>\n<ClrSysMmbId>\n<MmbId>123456780</MmbId>\n</ClrSysMmbId>\n</FinInstnId>\n</DbtrAgt>\n<UltmtDbtr>\n<Nm>Chandler Bing</Nm>\n<PstlAdr>\n<StrtNm>Senator Royall Drive</StrtNm>\n<BldgNb>2109</BldgNb>\n<PstCd>28262</PstCd>\n<TwnNm>Charlotte</TwnNm>\n<CtrySubDvsn>147</CtrySubDvsn>\n<Ctry>US</Ctry>\n<AdrLine>2109 Summertime Drive</AdrLine>\n</PstlAdr>\n<Id>\n<OrgId>\n<LEI>A1113456091873457567</LEI>\n</OrgId>\n</Id>\n</UltmtDbtr>\n<CdtTrfTxInf>\n<PmtId>\n<InstrId>Chan_InstrId__00000109</InstrId>\n<EndToEndId>Chan_E2E__00000109</EndToEndId>\n</PmtId>\n<Amt>\n<InstdAmt Ccy=\"USD\">109</InstdAmt>\n</Amt>\n<ChrgBr>SLEV</ChrgBr>\n<CdtrAgt>\n<FinInstnId>\n<ClrSysMmbId>\n<MmbId>987654320</MmbId>\n</ClrSysMmbId>\n</FinInstnId>\n</CdtrAgt>\n<Cdtr>\n<Nm>DEF Electronics</Nm>\n<PstlAdr>\n<StrtNm>Mark Lane</StrtNm>\n<BldgNb>55</BldgNb>\n<PstCd>EC3R7NE</PstCd>\n<TwnNm>London</TwnNm>\n<CtrySubDvsn>87RT</CtrySubDvsn>\n<Ctry>GB</Ctry>\n<AdrLine>9872 Univ Blvd.</AdrLine>\n</PstlAdr>\n<Id>\n<OrgId>\n<LEI>A1113456091873457568</LEI>\n</OrgId>\n</Id>\n</Cdtr>\n<CdtrAcct>\n<Id>\n<Othr><Id>12000194212188888</Id></Othr>\n</Id>\n<Prxy>\n<Id>5656565656</Id>\n</Prxy>\n</CdtrAcct>\n<!--\t<InstrForCdtrAgt>\n\t<InstrInf>OurRef:xyz9876541</InstrInf>\n</InstrForCdtrAgt> -->\n<InstrForDbtrAgt>ChanRef:abc123459</InstrForDbtrAgt>\n<Purp>\n<Cd>GDDS</Cd>\n</Purp>\n<RltdRmtInf>\n<RmtId>2020013116264838R008txuc4_rmt_good.</RmtId>\n</RltdRmtInf>\n<RmtInf>\n<Strd>\n<RfrdDocInf>\n<Tp>\n<CdOrPrtry>\n<Cd>CINV</Cd>\n</CdOrPrtry>\n</Tp>\n<Nb>4562</Nb>\n<RltdDt>2006-09-08</RltdDt>\n</RfrdDocInf>\n<!--RfrdDocAmt><DscntApldAmt><Tp><Prtry>NICK</Prtry></Tp><Amt>98700</Amt></DscntApldAmt></RfrdDocAmt-->\n</Strd>\n</RmtInf>\n</CdtTrfTxInf>\n</PmtInf>\n</CstmrCdtTrfInitn>\n</Document>",
"ref_transaction_id": null,
"ref_payment_id": null,
"appl_name": "abcdefg",
"ws_id": "2021081715553000000000002",
"priority": 71,
"timeout": 8000
}
Response
[{
"amount": 109,
"batch_id": 141027,
"creditor_name": "DEF Electronics",
"debtor_name": "Moon River",
"original_create_date_time": "2019-06-05T07:07:00",
"original_message_identification": "Chan_MsgId__00000109",
"timeout": false,
"transaction_id": 141028,
"transmission_id": 141026
}]
127253
Request for Information V2 (camt.026)
A new version (V2) of the Request For Information web service was created. The existing web service API was marked as deprecated. For more information, refer to the openapi-transactions-3.2.9.yaml that is included in the entitled documentation.
V1 versus V2
Request for Information V1 is using the traditional WebSphere Application Server, for example, on a local install:
http://localhost:58080/ws/svc/reqinfotrans/
Request for Information V2 is using WebSphere Application Server Liberty and Digital Payments FTM:
http://localhost:57107/transactions/reqinfotrans_v2
While V1 and V2 use the same content for the request payload and the response, V1 is using the camel case while V2 is using the snake case naming convention.
Usage
POST http://localhost:57107/transactions/reqinfotrans_v2 where uow_value is the transaction ID of the inbound credit transfer (pacs.008).
Example
Request
POST http://localhost:57107/transactions/reqinfotrans_v2 HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: application/json
x-ftm-audit-source: aaa
x-ftm-audit-host: bbb
Content-Length: 243
Host: localhost:57107
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.5.5 (Java/12.0.1)
Authorization: Basic ZnhoYWRtaW46ZnhocGFzcw==
{
"uows": [ {
"uow_type": "TRANSACTION_ID",
"uow_value": 15055
}],
"justifications": [ {
"information": "test1",
"type": "IncorrectNarrativeInformation"
}],
"initiator_type": "Financial Institution"
}
Response
{"15055": {
"message": "Successfully created",
"uow": {
"uow_type": "TRANSACTION_ID",
"uow_value": 15055
},
"status": "200"
}}
127942
Payment profile IDs reduced to lengths that are fewer than 34 characters
When integrated with TCH, registered Zelle tokens are restricted to a maximum of 34 characters per the EWS technical documentation. FTM previously created a unique 36-character UUID for each token that was newly registered.
An example of a generated profile ID looks something like this: 91fb2605-1926-3b7d-a181-f8eab29a666b
FTM is being updated to remove the dashes from the generated payment profile ID. This will reduce the length of the generated profile ID to 32 characters.
So, the previous profile ID now looks like this: 91fb260519263b7da181f8eab29a666b
Currently, no changes are required for all existing 36-character payment profile IDs. This change affects only newly registered tokens going forward.
Migration
- DSUmigration_v3.2.9.pdf
- DSUMigrationBR_v3.2.9.pdf
These documents are provided in the entitled documentation fix pack. The entitled documentation fix pack for Digital Payments can be downloaded from Fix Central by using the following link:
3.2.9-FTM-DP-MP-Documents.
Was this topic helpful?
Document Information
Modified date:
24 February 2023
UID
ibm16517458