A developer finds an official statement API. Finance already has a merchant portal login. It is tempting to treat the API as a ready replacement for the monthly download task.
There is still a dependency to resolve: does the documented service apply to this merchant, this platform and this production arrangement? An API's existence establishes an option to investigate. It does not establish that the finance team's current account can use it.
I work on BrowserAct's content and workflow documentation. This AI-assisted design example is derived from our Fiserv guide. It uses synthetic local qualification records, makes no API requests, and reports no authenticated statement download or tested BrowserAct collector.
Keep the two sources of access separate
The guide covers the documented US Commerce Control Center path: Statements, Summary and Documents, Monthly Statements, then the relevant type, view, year and month. It also discusses a separate published statement API with production prerequisites, including an approved key and the relevant gateway and settlement/funding onboarding.
Those descriptions must not be collapsed into a claim that every US Commerce Control Center user is eligible for the documented API. Products and regional platforms can have different arrangements. The qualification decision needs the actual service context, rather than a vendor-wide supports_api flag.
Start by writing down the required output. A monthly merchant statement PDF is different from a transaction report, funding export or supplier purchase invoice. Listing statement metadata is also different from saving the requested statement PDF. This distinction belongs in the integration's acceptance criteria before choosing its transport.
Record what was confirmed, not a credential value
The following precheck operates on an internal qualification record. It deliberately contains no secret keys. Approval references should point to controlled evidence; the program does not need to put credentials in a ticket, log or exported report to explain why a service was selected.
Use the exact platform and region identifiers from the real onboarding arrangement. The names below describe application fields, not Fiserv's response schema or a universal naming convention.
def qualification_gaps(request, approval): gaps = [] for field in ("merchant_ref", "platform_ref", "region_ref"): value = request.get(field) if not isinstance(value, str) or not value.strip(): gaps.append(field + "_missing") elif value != approval.get(field): gaps.append(field + "_mismatch") requirements = ( "production_key_approved", "gateway_onboarding_confirmed", "settlement_scope_confirmed", "statement_pdf_scope_confirmed", ) for name in requirements: if approval.get(name) is not True: gaps.append(name) reference = approval.get("evidence_ref") if not isinstance(reference, str) or not reference.strip(): gaps.append("approval_evidence_missing") return gaps An empty gap list means the supplied internal record satisfies this proposed precheck. It is not proof of live authentication, authorization, API availability or successful PDF retrieval. In production, qualification records must come from a trusted review process and be revisited when account or service scope changes. A caller cannot establish its own approval merely by sending these flags.
The statement_pdf_scope_confirmed flag is intentionally more specific than “API enabled.” If the task needs a file, confirm the applicable service and output scope. Do not let a successful metadata listing silently satisfy the file requirement.
A gap list is a handoff, not a retry instruction
Different gaps belong to different owners. A platform mismatch needs service qualification. Missing onboarding evidence needs confirmation through the existing integration process. A missing merchant reference needs a corrected task brief. Repeating an HTTP request does not resolve any of those dependencies.
While qualification is pending, keep the ordinary authorized portal task explicit. This is a decision about work allocation; it does not grant a browser worker permission or prove that its document-save path has been tested. A proposed API collector and a proposed browser collector each need their own execution evidence.
Once the API is properly qualified, test a small expected set: a named merchant, one known statement period and the required statement type. Compare the saved PDF with that request, not merely the response status. Keep the listing result and the file receipt separate so a successful discovery step cannot hide a failed document transfer.
Preserve the finance checklist during migration
A transport change should not remove the expected merchant-and-period checklist. Keep the same expected records when comparing the existing manual process with an API trial. Record missing months and mismatched merchants individually rather than describing the whole account as “synced.”
Retain prior accepted files when resolving exceptions. If the service supplies a corrected document later, preserve the version context instead of silently replacing an accounting artifact. Migration success means the intended records arrive with a checkable identity and location; fewer clicks alone is not that evidence.
The accompanying synthetic checks exercise account, platform and region mismatches, missing onboarding flags, absent approval evidence and a complete internal record. They do not exercise Fiserv production credentials or a merchant statement service.
Source and regional limits: Download Fiserv monthly statements in Commerce Control Center. The portal/API distinction comes from that source guide; the qualification schema and Python precheck are proposed integration design.
