---
title: Understanding Payment Statuses
description: "VendorHearth Pro tracks payment information separately from the status of a vendor's application. Understanding this distinction makes it easier to determine whether a vendor has simply been approved or has actually completed the required payment. ## Application Status vs. Payment…"
url: "https://vendorhearth.com/docs/understanding-payment-statuses/"
updated: "2026-09-23"
category: Payments — Square, payment statuses, deadlines, reconciliation, manual payments
---

# Understanding Payment Statuses

VendorHearth Pro tracks payment information separately from the status of a vendor's application.

Understanding this distinction makes it easier to determine whether a vendor has simply been approved or has actually completed the required payment.

## Application Status vs. Payment Status

An application status describes where the vendor is in the application process.

Payment information describes whether the required payment has been completed.

For example, a vendor may be:

**Approved and Awaiting Payment**

This means the vendor has been accepted for the event but has not yet completed the required payment.

Once payment is successfully completed and recognized, the vendor can become confirmed for the event.

## Awaiting Payment

After an application is approved, VendorHearth may place the application into an **Awaiting Payment** state.

At this point, the vendor has been accepted but still needs to complete payment.

The vendor should not be treated as fully paid simply because the application was approved.

## Confirmed / Paid

Once the required payment has been successfully completed or appropriately recorded, VendorHearth can recognize the vendor as confirmed.

A confirmed vendor has completed the payment requirement associated with that application.

## Square Payments

When a vendor pays through the VendorHearth Square integration, VendorHearth maintains the corresponding payment information.

Square can also send payment updates to VendorHearth through the configured webhook.

This helps VendorHearth keep its payment records synchronized with the transaction.

## Manual Payments

Organizers may sometimes need to record a payment that did not originate through the VendorHearth Square checkout.

Examples might include an approved payment method handled outside VendorHearth or a payment completed before the vendor was entered into the system.

These payments should be recorded as manual payments rather than represented as Square transactions.

## Historical Payments

Historical payment records are especially useful when moving existing vendors into VendorHearth.

For example, if a vendor paid through your previous registration system before you began using VendorHearth, the vendor can be entered as already paid.

VendorHearth can maintain a labeled historical/manual payment record so the vendor's status is accurate without creating a fake Square transaction.

## Do Not Mark Vendors Paid Without Payment

Only mark a vendor as paid when you have verified that payment was actually received.

Changing a payment status simply to move an application through the workflow can create inaccurate financial records.

If payment was received outside Square, use the appropriate manual payment option instead.

## Payment Status Can Affect Other Features

Accurate payment information is important throughout VendorHearth.

Depending on the workflow, payment status may affect whether a vendor is treated as confirmed for an event and may also be relevant to:

- Event rosters
- Season Passes
- Reports and exports
- Vendor records
- Event planning

Keeping payment records accurate helps keep these other areas accurate as well.

## When a Payment Looks Incorrect

If a vendor says they paid but VendorHearth does not show the expected payment information:

1. Verify the transaction in Square.
2. Confirm that the payment belongs to the correct vendor/application.
3. Check the VendorHearth payment record.
4. Verify the Square webhook configuration if the payment occurred online.
5. Confirm that the correct Square environment is being used.

Do not create a second payment simply because the first payment has not appeared correctly.

Investigate the existing transaction first.

## Keep Payment Records Accurate

VendorHearth is designed to distinguish between different ways payments enter the system.

Whenever possible, the payment record should reflect what actually happened:

**VendorHearth/Square payment → Square transaction**

**Payment received outside VendorHearth → Manual payment**

**Payment completed before migration → Historical/manual payment**

Maintaining this distinction provides a clearer and more accurate payment history.

## Next Step

Continue to **Recording Manual and Historical Payments** to learn how to handle legitimate payments that were received outside the normal VendorHearth Square checkout process.
