# Information sources for troubleshooting There are many sources of information at your fingertips to help you troubleshoot payments with FinDock. Some are core features of Salesforce, and others are built into the custom features and objects of FinDock. ## Monitoring with Salesforce features and tools Salesforce [reports and dashboards](https://help.salesforce.com/s/articleView?id=analytics.analytics_overview.htm&type=5) are great tools for FinDock admins and payment operations users who need to stay on top of payments in Salesforce. Salesforce dashboards provide valuable insights and simplify operations by helping identify and resolve issues more efficiently. To monitor overall payment system health and streamline troubleshooting, we highly recommend creating dashboards for key FinDock and Salesforce objects used in payment processing. To help you get started, FinDock Labs offers pre-built health check reports and dashboards for ogs using Fundraising (NPC, EDU) or Nonprofit Success Pack (NPSP) as a [source](/docs/source-connectors). Install these directly if they fit your purposes or simply use them as inspiration for creating your own monitoring tools. * [Health check for Fundraising](https://github.com/FinDockLabs/findock-healthcheck-fundraising) * [Health check for NPSP](https://github.com/FinDockLabs/findock-healthcheck-npsp) In addition to dashboards, list views are a simple yet important entry point for troubleshooting. Make sure your Salesforce users who troubleshoot FinDock have access to tabs and (custom) list views to key objects. ## FinDock custom objects Supporting each phase of the payment lifecycle are custom objects from FinDock that are essential sources of information for diagnosing and resolving issues. ## Schedules FinDock has four objects to control schedules: Payment Schedule, Recurring Payment Schedule, Mandate Schedule, and Recurring Mandate Schedule. Particularly the Payment Schedule object plays a central role in troubleshooting payment collections. ## Inbound Reports The Inbound Report object captures incoming payment intent data, such as payer details, amount, frequency, payment method, and so forth. Inbound Report records are also used to capture changes during the collection and reconciliation process, for example, based on notifications from a PSP. Inbound Report records are processed through [Guided Matching](/docs/reconciliation/what-is-guided-matching) and linked to related records for objects such as Payment Profile, Installment, and Account or Contact. FinDock uses the data from the inbound report to create or update these records, matching and enriching payment-related data. How FinDock processes an inbound report depends on the report type and subtype. The types and subtypes available in a given org depend on which payment processors and methods are used. However, they fall into three main categories: payment intents, PSP notifications, and files. ### Inbound reports for payment intents Every org has the PaymentIntent Inbound Report type (subtype Default) to capture new payments and match or create related records. ### Inbound reports for PSP notifications For each PSP, FinDock handles a number of webhooks and notifications as a payment is processed. The PSP package defines the Inbound Report type, and each notification has its own subtype. There can be a few subtypes, or a dozen or more. You can use the Guided Matching Setup tab to see the range of subtypes for your PSP, like Stripe here: Inbound report types for Stripe PSP notifications serve various purposes: * Confirmation or acknowledgement Typically these do not include actionable payment data, so FinDock does not automatically process them. The resulting inbound reports are usually given the status Manual, indicating they are not processed by Guided Matching without further intervention. * Setup and registration FinDock relies on these to, for example, create or update payment profiles and activate new mandates. They may also process cancellations or rejections that update related records. For recurring payments with an initial payment collection, these notifications handle both mandate creation and payment reconciliation. * Reconciliation These provide essential status updates on payment collection, refunds and rejections. These updates are reflected in installments and generate corresponding Payment records. ### Inbound reports for files Some PSPs and payment methods rely on file-based processing to collect and reconcile payments. This includes native FinDock processing, like Bacs Direct Debit, which has five file types that are represented as Inbound Report subtypes, as pictured below. Inbound report types for Stripe ### Transaction Set and Transactions The Transaction Set object represents an [incoming bank file](/docs/reconciliation/processing-bank-statements) containing one or more payment entries. Entries in the set are parsed into Transaction records. The Transaction Set and Transaction objects are linked through a Master-Detail relationship. In many cases, transaction sets and transactions are [automatically matched](/docs/reconciliation/processing-bank-statements#automatic-matching-on-processinghub) through ProcessingHub. However, Guided Matching is also used to match or enrich the results. ## Message The Message object is used to queue asynchronous processing tasks. In most cases, Message records are not part of day-to-day operations. They only become relevant in exceptional cases requiring deeper analysis for troubleshooting. From a technical perspective, each Message record represents a unit of work that FinDock places into an internal queue. These messages are picked up by inbound or outbound queue handlers, which then invoke the appropriate handler classes to perform the required actions asynchronously. When a new payment is created via the Payment API, using, for instance, a paylink, FinDock first creates a Message record containing all the day in the request and queues it for asynchronous processing. A Guided Matching Queueable Job is also enqueued which is responsible for creating the related Inbound Report record for the payment intent and executing all applicable Guided Matching rules. FinDock follows the same approach with PSP notifications. When a webhook notification arrives at the Notification Gateway, a Message record is created and queued for processing. For certain cases, Message records can provide valuable insights into system behavior and help identify where a process may have stalled or failed. Key fields to check include: * **Type**: each message is either Inbound or Outbound. Payment intents and PSP notifications, for example, are inbound. Payment instructions from FinDock to the PSP are outbound. * **Status**: by default this is set to Scheduled and automatically updated as the message is processed. Changes to Queued and Finished indicate success. If an error occurs, the status is changed to Failed. ## Log FinDock uses the Log object to record events generated by system components. These logs are essential for diagnostics, providing a clear trace of what occurred during a process. Key fields include: * **Message**: long-text form of the log entry * **Origin**: the function or class (such as an Apex class name) that produced the log * **Type**: event type that triggered the log: Information, Warning, or Error.