# API integration checklist

There are many use cases for the FinDock Payment API and many ways to implement each one. To help you find the best way to use the Payment API for your organization, we have collected a number of questions to help guide your development planning.

## Checklist

- Do you [dynamically](/api/getting-started-with-the-payment-api-v2#step-3-create-the-submission-form) make *payment methods* available for your front-end based on a GET to the `/PaymentMethods` endpoint?
- Do you dynamically make payment method *parameters* available for your front-end based on a GET to the `/PaymentMethods` endpoint?
- Do you dynamically make payment method *parameters values* (for `enum` type parameters) available based on a GET to the `/PaymentMethods` endpoint? For instance, do you show `issuers` for iDEAL payments based on the `enum` object?
- Do you offer both *one-time* and *recurring* payments?
- Do any processors require an initial payment to authorize recurring payments (thus using the `RecurringRequiresInitialPayment` parameter)?
- What are the [deduplication rules](/docs/reconciliation/processing-and-reconciling-online-payments#configuring-deduplication) for the org and how do they affect what data you collect and send through the API?


## Advanced questions

- Do you support *multiple currencies* through the `CurrencyISOCode` parameter?
- Do you support *multiple merchants* through the `Target` parameter?
- Do you allow your customers to add *(custom) fields* to the API call through the `SalesforceFields` object for:
  - `One-time`, `Recurring` and `PaymentIntent` (Inbound Report record)
  - `Contact` and `Account`
- Do you ensure the same payment is *not* offered to FinDock twice by implementing the `IdempotencyKey` parameter?
- If you store data in the application that calls the Payment API, do you handle payment data updates through *webhook notifications* from FinDock?


## Protecting API integrations

Whether you are using a custom integration or an out-of-the-box solution link [Giving Pages](/docs/payments/configuring-giving-pages), you may be susceptible to malicious actors trying to disrupt your payment channel. It is important to consider protecting online payment forms as part of your overall security strategy.

We have seen cases where bots and scammers use card testing data, i.e. legitimate test cards from PSPs, to generate large numbers of payment intent calls to the Payment API. This impacts performance and can prevent legitimate payers from completing their payments.

Here are some suggestions for protecting API integrations:

* Implement a bot check like reCAPTCHA and configure a threshold suitable for your site to reliably identify real payers
* Hire a third-party service like Cloudflare to implement full-feature protection
* If you have a custom integration, you implement an Idempotency key in the [payment intent](/api/payment-api-v2/payment-intent/paymentintent#path=idempotencykey). You can make your own choices for idempotency, but one option is to pass the session Id and IP address in the payment intent call.