SMART Exchange – Sending Payments 

Overview: SMART Exchange Payment Management

Utilizing SMART Exchange for payment management establishes a digital connection point between payers and receiving businesses, facilitating smooth transactions. The process initiates when a payment is created through the POST Create Payables API, which is responsible for capturing and securely storing all the necessary payment information. 

If the payment receiver is not yet enrolled in the SMART Exchange network, the first initiated payment will automatically begin an “onboarding with payment” workflow. This approach streamlines the process by integrating both onboarding and payment, ensuring the vendor is fully onboarded before any funds are released. 

For receivers already part of the network with a default payment method set, they will receive a notification indicating that the payment has been sent using their preferred method. If a receiver has not yet selected a default payment method, they will be prompted to access their account and choose their preferred payment option. 

Problem Statement: Challenges of Traditional Vendor Payments

Traditionally, paying businesses involves significant manual effort, including the verification of payment details and maintaining compliance. These tasks are often slow and susceptible to errors, which can lead to payment delays, strained relationships with vendors, and possible disputes. Additionally, the absence of a centralized system to track and manage vendor payments results in limited visibility into vendor performance and associated costs.  

Solution: Streamlined B2B Payments with SMART Exchange 

The POST Create Payables API endpoint helps overcome these challenges by streamlining the creation of payables, onboarding businesses to the SMART Exchange network as needed, and managing payments to receivers using their preferred payment methods. By leveraging this API call, businesses can send payments efficiently and securely, minimizing manual errors and ensuring all required details are accurately recorded and safeguarded by Transcard. 

 

Use Case 1: Receiving Business is not on the Exchange Network 

If a SMART Exchange payment is sent to a business who is not yet on the network, they will need to onboard before receiving the payment using the POST Create Payables API endpoint. 

Scenario 

A business, ACME Inc. (the payer), needs to pay a business, Wonka Ventures (the receiver), via the create payable API for a recent purchase. This payment would kick off the onboarding process and ensure that the receiving business payment details are accurately captured, and the payment tracked. 

Steps 

  • ACME Inc. collects the necessary company information and payment details from Wonka Ventures. 

  • ACME Inc. makes a POST request to the Create Payables API endpoint, including all required payload in the request body. 

  • The API call creates a new Party Record for Wonka Ventures and generates an associated payable with the specified payment details. 

  • Wonka Ventures receives an onboarding with a payment token which they can click through to, ensure their business information is correct, select their preferred payment method, and create a SMART Hub account where they can later view and download payment details. 

  • If Wonka Ventures passes all compliance checks, the payment will be routed via their selected method of payment. 

  • ACME Inc. can now track the payable and manage future payments to Wonka Ventures through the API's enhanced visibility features.

Use Case 2: Receiving Business is on the Exchange Network 

If a SMART Exchange payment is sent to a business that is already a part of the Exchange network, onboarding is not required, instead, one of two scenarios will occur: 

  1. The payer’s available payment methods match at least one of the preferred methods of payment set up by the receiving business, resulting in an automatic payment being initiated to the receiver.

  1. The receiving business will be prompted to login to their SAMRT Hub account to select an available method of payment (offered by the payer) and once selected the payment will be sent.

Please note: For both scenarios, the assumption is that the receiving business has passed compliance screening and is in good standing. If at any point the receiving business is on a compliance hold, payments will be held until the issues are remediated

Technical Details 

This guide provides step-by-step instructions on how to send a SMART Exchange payment. It outlines how to initiate the payment through the Create Payable API endpoint as SMART Exchange payments are not initiated through a user interface, yet. 

Instructions 

1. Set Up Your Origination Account 

To send a SMART Exchange payment, an origination account is required. Ensure that bank accounts are added during the SMART Enroll onboarding process. The appropriate account can be determined when initiating the payment. 

2. Initiate the Payment 

SMART Exchange payments are initiated via the Create Payables API call. Here are the steps: 

Request Body 

The request body will include the following fields: 

  • payableReferenceId: Shared identifier between payor and payee, like an Invoice ID or Purchase Order number. Aids in transaction reference, simplifying communication and reconciliation. 

  • recordNumber: Unique identifier for the payable, generated by your company. Can be an internal Bill ID, or Global Unique Identifier (GUID). Used for mapping in the Payables API, webhook notifications, and API updates. 

  • netTotal: The final total amount payable after all adjustments, discounts, and taxes. This field is required. 

  • isoCurrencyCode: The three-letter ISO currency code representing the currency of the payable, such as "USD" for US Dollars.  

  • payableTerms: The payment terms agreed upon, indicating when payment is due, commonly expressed as "NET30" meaning payment is due 30 days after the invoice date.  

  • payableDueDate: The date by which the payable must be settled.  

  • payableEffectiveDate: Scheduled payment processing date. It must be in date format and equal to or later than today. It can match payableDueDate or be set to today for same-day processing. 

  • payableApprovalStatus: Status indicating the readiness of a payment for processing. With 1 (Hold), the payment awaits further action and won't process immediately. With 2 (Release), the payment is set to proceed. 

  • memo: A text note providing additional context or description for the payable. 

remittance: 
Encapsulates details for the payment remittance. Contains totals, adjustments, and linelevel information. 

  • grossTotal: Total payable amount before deductions. Usually matches netTotal. 

  • grossDiscount: Any discount applied to the payable (e.g., early payment discount). Default 0.00 if not used. 

  • tax: Total applicable taxes for the payable. Default 0.00 if not used. 

  • lineItems: An array of line-level details tied to an invoice or payable. Leave empty if unnecessary. 

payees: 
An array that contains information about the party receiving the payment. SMART Exchange currently only supports one payee. 

  • partyReferenceId: Unique identifier for the payee within your system or generated GUID. Mandatory. 

  • businessName: Registered business name, or name of an individual if business is sole proprietorship. 

  • isBusiness: Boolean indicating payee type (true = business, false = individual). All SX payments recipients are businesses. 

  • identifiers: Array of identification details (e.g., US_TIN, SSN, EIN). 

  • identificationType: Classification of identifier, e.g., US_TIN. 

  • identificationNumber: Actual identifier value. 

  • emailAddress: Recipient email. Required if using email for token delivery or notifications. 

  • phoneNumber: Recipient’s primary telephone number. 

smartExchange (inside payees): 
Specifies how the SMART Exchange payment functions for this payee. 

  • isPrimary: Indicates whether this payee is the primary recipient (required and should be true). 

  • amount: The total payment allocated to this payee. Should match netTotal if there’s only one payee. 

  • securityQuestions: Array of challenge/response questions used for verification with a minimum of 1 required.

  • languageCode: Language of the question (e.g., en-US). 

  • question: Security question text. 

  • answer: Expected answer. 

  • tokenDeliveryMethods: Defines how the recipient receives SX notifications/tokens. Supported options: emailAddress, phoneNumber. 

address (inside payees): 
Physical location of the payee. Required for regulatory and audit purposes. 

  • addressLine1, addressLine2, addressLine3: Street address components. 

  • townName: City. 

  • countrySubDivision: State, province, or regional subdivision (e.g., TX). 

  • country: Country name/abbreviation (USA). 

  • postCode: ZIP/postal code. 

paymentInfo: 
Holds details about origination, destination, and method of payment for the payable. 

  • originationAccountReferenceId: Identifier for the originating account funding the payment. This field is required. 

  • destinationFinancialInformation: Payment method and destination details. 

  • isoCurrencyCode: Currency used at the destination. 

  • methodOfPayment: Numeric code that dictates which rail to use (“8” for SX). This field is required. 

smartExchangeDetails: 
Controls how the SMART Exchange experience appears to recipients. 

  • languagePacks: Array defining localized text content for the payment screens. 

  • languageCode: Language, locale code (e.g., en-US). 

  • isDefault: Boolean indicating default language pack. 

  • paymentTypeText: Label describing payment type. 

  • paymentMessage: Text describing the purpose/details of the payment. 

  • paymentMessageHeaderText: Header above the payment message. 

  • signatureHeaderText: Header shown before recipient signature field. 

  • welcomeMessage: Greeting text. 

  • documentsHeaderText: Header for supporting document section. 

  • documentMessage: Text instructing user on documents. 

  • contactEmailAddress, contactPhoneNumber: Contact information for issues/questions. 

  • learnMoreDetails: Free text for educational/disclosure info. 

  • signatureRequired: Boolean indicating if recipient signature is required before release. 

  • expirationDate: Date after which this SX payment link/token expires. 

  • behaviors: Supported disbursement methods (ACH, RTP, QuickPay, etc.). 

documents: 
An array containing any documents tied to the payable for recipient review. 

  • name: Filename of the document (e.g., Adjuster Report.pdf). 

  • description: Description or label of the document. 

  • contentByteArray: Base64encoded document content. 

 

Example Request Body 

To schedule a payment, follow these steps. The scheduling is based on the specified date. No workflow will execute until this date is reached, except for creating AP records, Parties, and Accounts. 

3. Confirm the Payment 

Accepting Request: The immediate HTTP response reflects if the request was accepted (202) or declined (400 or 500). Please note a 200 acceptance does not indicate that the workflow was processed, just that the api call was successful.  The corresponding webhook will denote the state of the workflow including any issues noted (example could be that there is a missing email address, etc).  

Webhooks: Payables and Receivables are event-driven processes. As each step of the workflow occurs and new statuses or states are obtained, a notice will be sent to stakeholders via webhooks.  This will include any status changes notified to Transcard by the Third-Party payment processor. 

Reconciliation: Confirmation of payment will need to occur through standard accounting reconciliation practices. Most Third-Party processors only communicate to Transcard that the payment request was initiated, or if the payment process failed at any point, but do not report back if funds movement were completed as a default behavior of the network. 

Troubleshooting 

If you encounter any issues, such as the payment method not being available for the selected bank account, contact Transcard support at 800-890-3128 or support@transcard.com for assistance. 

Conclusion 

This guide has provided the necessary steps to send a SMART Exchange payment using the Create Payables API call. Ensure that all required fields are correctly filled out in the request body to facilitate a smooth transaction. 

The POST Create Payables API endpoint is a valuable tool for businesses looking to streamline their vendor payment processes. By leveraging this API, businesses can reduce manual errors, ensure timely payments, and maintain transparent vendor relationships. The ability to initiate payments to multiple vendors without needing to maintain payment details makes this API an essential component of efficient vendor management.