An SDK can simplify calls to a payment API, but it does not decide how your orders or subscriptions should work. Choose against the provider’s contract, your project language and the maintenance you can support.
What work can it handle?
A library may help build requests, signatures, responses and error handling. Check its exact scope. Returning a payment object does not mean the sale has been updated, a document sent or service access opened.
Before adding the dependency
| Check | Evidence to look for |
|---|---|
| Origin | Official provider library or clearly identified third-party project |
| Compatibility | Supported language, runtime and API versions |
| Maintenance | Recent releases and issue handling |
| Contract | Available operations, parameters and errors |
| Integration security | Response validation and secret handling |
| Testing | Reproducible examples in the test environment |
A library using the processor’s name is not necessarily official. Record the version you have checked; instructions for another version may not apply.
SDK versus direct API calls
With an SDK, a dependency handles some connection code. Direct API calls leave more preparation and maintenance with your team. Either way, your application must connect the sale, payment request and result. Both approaches may use the same API.
A minimal journey is: application determines amount → operation created → customer pays → server validates result → sale updated once.
What should you test?
Check a valid response, invalid response, decline, timeout and repeated notification. A timeout leaves an outcome to resolve; it is not permission to charge again automatically. Our testing matrix separates these cases.
If you are also choosing the payment screen, see hosted checkout and APIs. A hosted checkout can itself use an API integration.
Start with AndorPay’s documentation, in Spanish, then check operations against the provider’s documentation before implementing them.