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 showissuers
for iDEAL payments based on theenum
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
andPaymentIntent
(Inbound Report record)Contact
andAccount
- 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.