Have something to say?
Add `deliveryMethod` template variable + generic inline mapping syntax to prefund description config
Context Partners can configure the prefund funds-transfer description string with templates like: PR {{paymentId}} {{buyAmount}} {{buyCurrency}} {{recipientLegalName}}[20] {{bankCountryCode}} See docs/prefund-description-config.md for the full reference. Recipient templates expose 8 variables today; there's no way to include the recipient's delivery method (SWIFT vs in-country EFT) in the description. Two related asks bundled here because they're best designed together: New deliveryMethod variable. Generic inline-mapping modifier on the template engine, so a single variable can render different strings per partner without backend code changes. Part 1 — deliveryMethod variable Add a new template variable on recipient prefund templates. Source field: recipient.liveData.DeliveryMethodId Raw values today (from TableConstants.js): W and E Default rendered output: W → Wire, E → Local Files to change (variable-map population in each rail adapter, recipient template only): graphql/src/paymentEngine/rails/InternationalUSDConsWire/InternationalUSDConsWireAdapter.js (~1483–1496) graphql/src/paymentEngine/rails/InternationalUSDCorpWire/InternationalUSDCorpWireAdapter.js (~1580–1593) graphql/src/paymentEngine/rails/InternationalFXConsWire/InternationalFXConsWireAdapter.js (~1536–1549) graphql/src/paymentEngine/rails/InternationalFXCorpWire/InternationalFXCorpWireAdapter.js (~1791–1804) Part 2 — Generic inline mapping modifier Extend FormatUtils.populateDynamicString() (graphql/src/utils/FormatUtils.js, ~L429-454) with an inline mapping modifier that lets a template override the rendered string per raw value. This is generic — works on any variable, not just deliveryMethod. Proposed syntax (engineering can finalize delimiter): {{deliveryMethod}} → "Wire" or "Local" (default mapping in the adapter) {{deliveryMethod|W=Swift|E=Local}} → "Swift" or "Local" (template-level override) {{deliveryMethod|W=SWIFT|E=ACH}}[6] → composes with existing [N] width modifier {{buyCurrency|USD=Dollars|EUR=Euros}} → works on any variable Semantics: If the modifier is present and the raw value matches a key, render the mapped value. If the raw value doesn't match any key in the modifier, fall back to the default rendered value (i.e. what {{var}} alone would render). This keeps the modifier additive — partners only spell out the cases they care about. The [N] width modifier applies after mapping: slice the rendered string, not the raw value. Delimiter (| proposed) must not conflict with any existing template content. If it does, pick another (;, ::, etc.) — flag in the PR. Caveats Recipient templates only. Vostro payments have no recipient and no delivery method. Don't add deliveryMethod to the vostro variable map (substitution throws on undefined variables — see existing caveat #2 in the doc). All 4 flavors (USD/FX × Consumer/Corporate) on the recipient path. Backwards compatible. Templates without the new modifier render unchanged. The modifier is a pure parser extension. Unknown variable still throws. The mapping modifier doesn't suppress th
onboard notifications
Add additional permission for parter user notification specifically around onboard.
Recipient sort and search consistency
recipient list back office: sort: recipient name, company name, search: is kind of case sensitive, this is not very consistent - should be non-case-sensitive, probably a mix of how we search for draft and non-draft: https://share.zight.com/qGuW5DYx end user: sort: name (by nickname), status, search: similar issue here with case-sensitivity https://share.zight.com/ApubzOm8
scrub description
when passing description to the platform for funds transfer, scrub out ampersand might be other characters to add to the list.
Download EULA
When users are presented with the EULA - allow them to download a PDF. Allow them to also request a copy to their email (attaching the pdf or link ) Subject: EULA Request from PayRecs
Custom PayRecs Brand Footer/Email
Allow for customization of PayRecs logos in the online portal and email
po box override
For various reasons, banks can't change the PO box address that is present in online banking In order to allow submission to processor, we need a way for the partner user admin to interdict the address. Scope if po box is identified and blocking occurs in the UI (next is grayed out) add a new model that pops up that says Please enter a physical street address. PO Boxes are not accepted for KYC verification and payment remittance." The new modal can capture the new address in a standard form on save, submit the manually entered address to processor, can keep the po box stored on the platformmemtata data ensure that we're not updating the address anywhere going forward (should just be from OB to platform metadata
Inline Company Address Edit
During onboarding, allow back office user to edit company name, address information before it is submitted to processor.
support widget spacing
Adjust the column and spacing for the support widget to support very long emails
Recipient search issues
When searching recipient list from the Backoffice (under company or the global recipient list), there appears to be issues when searching against draft recipients. Ensure that at least the draft nickname and legal name and account number are included as part of the search Current fields searchable for recipients: | Search Context | User Role | Fields Searched | | -- | -- | -- | | Recipient list page (partner view) | Back Office | nickname, company.name | | Back office recipient list (primary company) | Back Office | nickname | | Back office recipient list (secondary company) | Back Office | nickname | | Pay wizard "Who" search | End User | nickname, Currency, BeneficiaryName, |
Recipient invite disclaimer
Recipients may provide fraudulent or incorrect payment instructions. The reviewer is responsible for independently verifying all instructions through a trusted channel before submitting a payment
MCA start and end bals incorrectly including cancelled payments
Start and end bal queries should exclude cancelled payments. Cancelled payments should still be visible in the statement list but there amounts should affect running balances.
Okta/Microsoft SSO support
Allow backoffice users to authenticate with existing crednetiials - supporting Okta or Microsoft (Entra ID) [rimairly.
sync flavor transaction rights to payrecs
A new setting to sync the q2 flavor customer/user to payrecs - one way. don't allow updates on the payrecs side. make sure that syncs on sso for all users
Add tran code override for MCA destination
When originating from DDA to MCA, establish the ability to define a tran code override for this.
Subsidiary fee account edit
Subsidiaries should be able to edit Fee Account after creation
FI Revenue Report updates
FI Revenue - a same day rejected DIFF - shouldn't it show here, since FI Revenue was generated? The FI revenue shows on the RETURNED report https://share.zight.com/Z4u8gXO5 EOD Settlement report - Column T - show a sum total at the bottom EOD Settlement report - add fiFxRevenue and fiMarkupBp to the end of the report. Sum fiFXRevenue Bonus EOD Settlement allow for customization of the report columns - basically anything that is available in the predefined report, allow us to enter an array/list of column names in the partner.config report specification that will use those columns and the order of the columns to change out the report file is outputted ensure that SUM columns still sum (technically they are not required to show though)