In Progress
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 the existing "unknown variable name" crash — only the per-value mapping is overridable. Acceptance {{deliveryMethod}} substitutes to Wire / Local across all 4 recipient prefund templates. {{deliveryMethod|W=Swift|E=Local}} substitutes to Swift / Local. {{deliveryMethod|W=SWIFT}}[3] substitutes to SWI (mapping then truncate) when value is W, and to Loc (default mapping then truncate) when value is E. Generic modifier works on any other variable (test with buyCurrency or bankCountryCode). Vostro substitution unaffected — vostro templates that don't reference deliveryMethod continue to render correctly. docs/prefund-description-config.md updated: "Available variables → Recipient templates" table includes deliveryMethod row. "Template syntax" table includes the new mapping modifier. "Suggested templates" section gets one example using the modifier.
Linear about 1 month ago
In Progress
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 the existing "unknown variable name" crash — only the per-value mapping is overridable. Acceptance {{deliveryMethod}} substitutes to Wire / Local across all 4 recipient prefund templates. {{deliveryMethod|W=Swift|E=Local}} substitutes to Swift / Local. {{deliveryMethod|W=SWIFT}}[3] substitutes to SWI (mapping then truncate) when value is W, and to Loc (default mapping then truncate) when value is E. Generic modifier works on any other variable (test with buyCurrency or bankCountryCode). Vostro substitution unaffected — vostro templates that don't reference deliveryMethod continue to render correctly. docs/prefund-description-config.md updated: "Available variables → Recipient templates" table includes deliveryMethod row. "Template syntax" table includes the new mapping modifier. "Suggested templates" section gets one example using the modifier.
Linear about 1 month ago
Completed
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
Linear 2 months ago
Completed
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
Linear 2 months ago
Completed
scrub description
when passing description to the platform for funds transfer, scrub out ampersand might be other characters to add to the list.
Linear 2 months ago
Completed
scrub description
when passing description to the platform for funds transfer, scrub out ampersand might be other characters to add to the list.
Linear 2 months ago
Accepted / Design
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
Linear 3 months ago
Accepted / Design
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
Linear 3 months ago
Completed
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
Linear 3 months ago
Completed
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
Linear 3 months ago
Accepted / Design
Inline Company Address Edit
During onboarding, allow back office user to edit company name, address information before it is submitted to processor.
Linear 3 months ago
Accepted / Design
Inline Company Address Edit
During onboarding, allow back office user to edit company name, address information before it is submitted to processor.
Linear 3 months ago
Completed
Partner users being logged out after ~30 minutes due to IP whitelist failure on token refresh
Problem Partner users are seeing "client ip (missing) was not found on whitelist" after switching to another browser tab for 20-30 minutes and returning. This is causing confusion as users believe they have lost their session, when partner sessions are designed to last 16 hours without re-login. Solution Two issues to fix: 1. Keep the refreshToken heartbeat alive during tab inactivity 2. Fix error discrimination in the whitelist middleware
Linear 3 months ago
Completed
Partner users being logged out after ~30 minutes due to IP whitelist failure on token refresh
Problem Partner users are seeing "client ip (missing) was not found on whitelist" after switching to another browser tab for 20-30 minutes and returning. This is causing confusion as users believe they have lost their session, when partner sessions are designed to last 16 hours without re-login. Solution Two issues to fix: 1. Keep the refreshToken heartbeat alive during tab inactivity 2. Fix error discrimination in the whitelist middleware
Linear 3 months ago
Completed
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, |
Linear 3 months ago
Completed
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, |
Linear 3 months ago
Accepted / Design
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
Linear 3 months ago
Accepted / Design
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
Linear 3 months ago
Completed
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.
Linear 3 months ago
Completed
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.
Linear 3 months ago
Accepted / Design
Okta/Microsoft SSO support
Allow backoffice users to authenticate with existing crednetiials - supporting Okta or Microsoft (Entra ID) [rimairly.
Linear 4 months ago
Accepted / Design
Okta/Microsoft SSO support
Allow backoffice users to authenticate with existing crednetiials - supporting Okta or Microsoft (Entra ID) [rimairly.
Linear 4 months ago
Completed
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
Linear 4 months ago
Completed
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
Linear 4 months ago
Completed
Add tran code override for MCA destination
When originating from DDA to MCA, establish the ability to define a tran code override for this.
Linear 4 months ago
Completed
Add tran code override for MCA destination
When originating from DDA to MCA, establish the ability to define a tran code override for this.
Linear 4 months ago
Completed
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)
Steve Habegger 4 months ago
High Priority
Completed
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)
Steve Habegger 4 months ago
High Priority