Laravel Bog Sdk Laravel Package

Product Decisions This Supports

• Whether statement ingestion is trustworthy enough to ship. v1.1.0 fixes a truncation bug that silently capped stream() at the first page (1,000 records) instead of following TotalCount — verified at 2,893/2,893 for a full year. Any reconciliation, accounting export, cash-flow forecast, or underwriting model built on statements was previously operating on a partial year with no error surfaced. This is the gating question for any statement-dependent feature.
• Feature viability of balance and "today" views. balance()->get() was calling an endpoint Bonline rejects with HTTP 400 — i.e. the balance feature did not work at all. todayActivities()->get() returned DTOs with empty amounts because the feed uses different field names. Both are now mapped to real responses (AvailableBalance, CurrentBalance, StatementBalance, credit/debit/nomination). Balance-dependent UI (available funds, overdraft warnings, spend-today widgets) moves from "not buildable" to "buildable."
• Build vs. buy for bank connectivity. The package covers statements (paged + streamed), balances, today's activities, and now POS card-payment parsing. That is enough surface area for an in-house ingestion layer without an aggregator contract — worth pricing against Plaid/Tink-style per-connection fees if volume is meaningful.
• Roadmap sequencing. v1.1.0 is a credibility release, not a features release. The new CardPaymentDto::fromText() (gross, commission, net, terminal, merchant, address, auth code, deposit id) unlocks a second wave: expense categorization, merchant-level spend analytics, terminal/POS reconciliation, and fee (commission) reporting. These are differentiators that were not possible on v1.0.0.
• Data remediation and customer trust. If anything shipped on v1.0.0, previously exported statements were materially incomplete and "today" amounts were zero. A PM decision is owed: backfill historical pulls, audit dashboards that consumed entryAmountCredit-style fields (now documented as always-empty), and decide whether affected reports need correction notices.
• Vendor-risk posture. "Verified against the live API" with concrete record counts is the signal to weigh. The release is essentially a list of endpoint-shape mismatches — evidence the upstream API is undocumented or under-documented, which sets an ongoing maintenance tax and argues for contract tests pinned to live sandbox traffic.

When to Consider This Package

Consider adoption when:

• You are building inside Laravel/PHP and need Bonline account data — statements, balances, same-day activity — without standing up a separate service.
• Your use case is read-only ingestion: reconciliation, bookkeeping export, cash-position dashboards, spend analytics, or statement-based credit assessment.
• You need full-history statements, not samples — the TotalCount paging fix is the specific capability that makes year-scale pulls viable.
• POS/card settlement detail matters (commission vs. net, terminal and merchant attribution) and you'd otherwise be parsing free-text narratives yourself.
• You can absorb single-maintainer / undocumented-API risk and want to own that risk in-house rather than pay an aggregator to own it.

Look elsewhere when:

• You need write operations (payments, transfers, beneficiary management) — this package is read-only.
• You need multi-bank coverage — this is Bonline-specific; an aggregator is the correct buy.
• You require a support contract, SLA, or security attestation — none is implied here.
• You are not on Laravel/PHP — the DTOs and HTTP layer are the value; porting cost likely exceeds rewriting against the raw API.
• You are pre-revenue or pre-scale and the integration is a nice-to-have: the maintenance tax of chasing undocumented endpoint changes is real, and v1.0.0→v1.1.0 shows how much can be wrong before anyone notices.
• Strong compliance/audit requirements apply and you cannot independently verify data completeness — though note the streaming fix makes verification (compare TotalCount to ingested count) a tractable control you can build.

How to Pitch It (Stakeholders)

For executives: This is a Laravel library that pulls account statements, balances, and same-day transactions directly from Bonline. The new release is a correctness release: it fixes three bugs that made the integration quietly wrong rather than visibly broken — statements were being cut off at 1,000 records (now a full year, 2,893 of 2,893), the balance call was failing outright, and same-day activity amounts were coming back empty. It also adds structured parsing of card-terminal payments, which opens up merchant-level spend and fee reporting as a product surface. Net: the foundation is now sound enough to build customer-facing features on, and we should decide whether to remediate any data already pulled on the prior version. The main risk is dependency on an under-documented third-party API maintained by a small team.

For engineering: Treat v1.1.0 as the minimum version — do not ship against v1.0.0. One behavior change to plan for: todayActivities()->get() now returns TodayActivityDto[] instead of TransactionDto[]; if you read entryAmountCredit or similar, switch to credit / debit / nomination (the old fields were always empty, so no real data is lost, but type hints and property access will break). New surfaces available: CardPaymentDto::fromText(), TransactionDto::cardPayment(), TodayActivityDto::cardPayment() / isCredit(), and BalanceDto::$accountKey / $statementBalance. Recommend we add integration tests asserting ingested row count equals TotalCount and that balance/activity calls return non-empty amounts — that guardrail is what was missing and would have caught all three defects. Also worth pinning dependency versions and watching for the next upstream endpoint change, since the release notes are effectively a changelog of undocumented API shapes.