--- title: Understanding Payments in VendorHearth description: VendorHearth Pro includes payment management tools that connect vendor payments with applications and event participation. VendorHearth can process online payments through Square and can also maintain manual or historical payment records when a payment occurred outside the normal VendorHearth checkout… url: "https://vendorhearth.com/docs/understanding-payments-in-vendorhearth/" updated: "2026-09-23" category: Payments — Square, payment statuses, deadlines, reconciliation, manual payments --- # Understanding Payments in VendorHearth VendorHearth Pro includes payment management tools that connect vendor payments with applications and event participation. VendorHearth can process online payments through Square and can also maintain manual or historical payment records when a payment occurred outside the normal VendorHearth checkout process. ## Payments and Applications Payments in VendorHearth are connected to the vendor's participation in an event. A typical workflow may look like: **Application Submitted → Application Approved → Awaiting Payment → Payment Completed → Vendor Confirmed** This allows organizers to distinguish between a vendor who has been approved and a vendor who has actually completed payment. ## Approved Does Not Mean Paid An approved application may still require payment. VendorHearth keeps these stages separate so organizers can identify vendors who have been accepted but have not yet completed their booth payment. Once the required payment is successfully completed or appropriately recorded, the application can move into its confirmed state. ## Square Payments VendorHearth Pro includes Square payment support. When Square is properly configured, vendors can complete applicable payments through the VendorHearth payment workflow. VendorHearth's Square configuration includes: - Environment - Application ID - Location ID - Access Token - Webhook URL - Webhook Signature Key These settings connect your VendorHearth installation with your Square application. The complete setup process is covered in **Setting Up Square Payments**. ## Sandbox vs. Production Square provides separate environments for testing and live payments. **Sandbox** is used for testing. **Production** is used for real transactions. The credentials used for Sandbox and Production are different. Before accepting real vendor payments, make sure VendorHearth is configured with the appropriate Production credentials. ## Square Webhooks VendorHearth also uses a Square webhook to receive payment updates. The webhook allows Square to notify VendorHearth when payment information changes. VendorHearth's Square integration uses the `payment.updated` webhook event. Webhook configuration is important because a payment can change status after the initial transaction. We'll configure this as part of the Square setup documentation and explain it further in **Understanding the Square Webhook**. ## Manual Payments Not every payment needs to originate through VendorHearth's online checkout. VendorHearth can maintain manually recorded payment information when appropriate. This may be useful when a legitimate payment was received through another approved process. Manual payment records should represent payments that actually occurred. ## Historical Payments VendorHearth also supports historical payment records. For example, suppose you begin using VendorHearth after several vendors have already paid for an event through your previous system. Those vendors can be entered as already paid, and VendorHearth can create a labeled manual historical payment record. This allows VendorHearth to recognize the vendor's payment status without pretending that the original transaction occurred through the VendorHearth Square integration. ## Historical Payments Are Not Square Transactions A manually recorded historical payment is not a Square API transaction. VendorHearth keeps this distinction so your records accurately reflect how the payment was entered into the system. Do not create a fake Square transaction to represent a payment that occurred somewhere else. ## Payment Records Should Reflect Actual Transactions VendorHearth's payment history is most useful when it reflects what actually happened. For example: **Paid through VendorHearth/Square → Square payment record** **Previously paid outside VendorHearth → Manual or historical payment record** Do not mark an unpaid vendor as paid simply to move their application into a confirmed state. ## Payment Status and Application Status Payment information and application status are related, but they are not the same thing. A vendor might be: **Approved + Awaiting Payment** or: **Confirmed + Paid** Keeping these pieces of information separate gives organizers a clearer picture of the vendor's actual event status. ## Reviewing Payments VendorHearth provides payment-management tools so organizers can review payment information associated with vendors and applications. Payment records can also be included in VendorHearth reporting and exports. ## Before Accepting Online Payments Before opening online payments to vendors: 1. Configure your Square integration. 2. Verify the correct Square environment. 3. Verify the Application ID. 4. Verify the Location ID. 5. Verify the Access Token. 6. Configure the Square webhook. 7. Verify the Webhook Signature Key. 8. Test the payment connection. Do not assume that entering only the Square Application ID is enough to complete the integration. ## Keep Square Credentials Private Square access tokens and other sensitive credentials should be treated as private information. Do not publish them in documentation, screenshots, support posts, or other public locations. Only authorized administrators should have access to the payment configuration. ## Next Step Continue to **Setting Up Square Payments** for a complete walkthrough of creating or selecting your Square application, locating the required credentials, configuring VendorHearth, setting up the webhook, and preparing the integration for testing.