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 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)?

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, 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 object. 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.

Was this page helpful?