PayFabric Integration Known Limitations

This article describes the known limitations of the PayFabric integration. They are inherent to the current design of the integration and the capabilities of the PayFabric platform, and they apply to all subscribers. Use this document alongside the mapping documentation to set expectations before configuring the integration.

This integration is built for PayFabric, using PayFabric's Receivables Sync API (customers, invoices, and payments) and PayFabric's Payment / Gateway service (refunds and voids). PayFabric does not publish a stable, versioned public API; the integration was built against PayFabric's documented production endpoints and last validated end-to-end against the PayFabric sandbox environment as of 2026-06-18. The production instance URL is provided by PayFabric for your account.

Not built for: other Nodus / PayFabric product surfaces beyond the Receivables Sync and Payment/Gateway services described here. If PayFabric introduces a separate product line or a materially different API, this integration will not automatically support it.

The integration creates and updates records in PayFabric but does not delete them. Deleting a customer, company, or invoice in iPaaS.com does not remove the corresponding record in PayFabric, and delete mappings are not included in the default templates.

What this means for you: Manage record removal directly in PayFabric. If your workflow needs deletions to flow from iPaaS.com to PayFabric, submit a feature request through your iPaaS.com partner channel describing the requirement.

PayFabric does not have a separate "company" entity. iPaaS.com companies are written to PayFabric as customer profiles, distinguished by a COMP-prefixed CustomerId, through the Add/Update PayFabric Company FROM iPaaS.com collection.

What this means for you: Both the Customer and Company collections write to PayFabric customers. Decide the source of truth for each before enabling both, and avoid using a COMP-prefixed identifier for a regular customer so the two never collide.

Before creating a customer (or company-as-customer), the integration checks the email address. If a PayFabric customer with that email already exists, the existing customer is updated instead of creating a new record. PayFabric itself permits multiple customers to share an email; the integration's check prevents duplicates from iPaaS.com.

What this means for you: Two distinct iPaaS.com customers that share an email address will map to a single PayFabric customer. Use unique email addresses where each iPaaS.com customer must remain a separate PayFabric customer.

PayFabric customer and invoice records do not expose subscriber-mappable custom fields. Values are written through the standard fields documented in the mapping documentation.

What this means for you: You cannot map arbitrary iPaaS.com values into PayFabric custom fields. Note that the reverse is supported where needed — the integration reads several iPaaS.com source custom fields (such as Currency, Batch Number, Payment Terms, Due Date, and the refund-tracking fields) to build invoices and refunds.

Refunds and voids are processed through PayFabric's Payment / Gateway service, which authenticates with the Device ID and Device Password credentials — separate from the Integration Key and Integration Password used for customers and invoices. PayFabric records a refund as a Payment record (with a Refund payment type) and updates the invoice balance.

What this means for you: If you need refunds, configure the Device ID and Device Password presets. If you do not configure them, customer and invoice sync still work, but refunds and voids will not.

A refund can only be posted when the invoice already exists in PayFabric and has a payment in an approved status, and when the iPaaS.com refund custom fields are populated (Refund Amount, PaymentId, Transaction Key, IsRefundable). The custom fields RefundPaymentIdentity, OriginationID, and AlreadyRefunded must exist in iPaaS.com before a refund is initiated.

What this means for you: Sync the invoice and its payment to PayFabric first, create the required custom fields in iPaaS.com, and populate the refund custom fields before initiating a refund.

The integration supports a single refund payment record per invoice. Additional refund records linked to the same Transaction Key overwrite the previous refund amount rather than accumulating as separate refunds.

What this means for you: Plan for one refund per invoice through the integration. If your workflow requires multiple distinct partial refunds recorded separately on one invoice, validate the behavior in a staging environment and submit a feature request if it does not meet your need.

When PayFabric payments are synced to iPaaS.com, the payment method on the PayFabric payment must already exist in iPaaS.com. If it does not, the payment transfer reports an error and the payment is not created.

What this means for you: Create the payment methods you use in PayFabric in iPaaS.com ahead of time. The error message names the specific method that needs to be created.

Invoice and payment changes in PayFabric are retrieved by polling on the integration's schedule, not in real time. The look-back window for the first poll is controlled by the Invoice Poll Search Days setting (the number of days before the current time the integration searches).

What this means for you: Expect a short delay between a change in PayFabric and its appearance in iPaaS.com. Set Invoice Poll Search Days high enough to capture the history you need on the first poll.

The integration transfers records as they are created, updated, or polled; it does not include a built-in mode to bulk-load an entire history in one operation.

What this means for you: For a large initial load, use the supported bulk sync using Postman approach.

PayFabric requires an invoice line item's ItemCode to be no more than 50 characters. The integration derives the ItemCode from the iPaaS.com SKU and truncates it to the first 50 characters.

What this means for you: If your SKUs exceed 50 characters, make sure they remain unique within their first 50 characters so different products do not collapse to the same PayFabric ItemCode.

Invoice status is converted between iPaaS.com and PayFabric through lookup translations (one per direction). The value pairs are configured per environment and are not guaranteed to match your PayFabric status set out of the box.

What this means for you: Review the PayFabric Invoice Status translations in iPaaS.com and confirm the value pairs match the statuses your PayFabric account uses before relying on the integration in production.

The default templates ship with example values that each subscriber should review and replace where appropriate:

These twelve limitations reflect the current design of the PayFabric integration and the capabilities of the PayFabric platform. For field-level detail on how each entity is mapped, see the PayFabric mapping documentation articles.