extend models to fit linkpay additions on payment links - UOD-3819

[denis-shtupa-unzer]

No description provided.

[Copilot]

Pull request overview

This PR extends the v0 Payment Links model/types to include additional Linkpay-related fields and introduces a new test covering paymentLinks.getById.

Changes:

• Extended PaymentLinkDto and PaymentLinkQuery with additional fields (e.g. solutionType, multiUse, expiresAt, alias, orderCount, deleted, etc.).
• Changed PaymentLinks.getById to return a new “detail envelope” type instead of a single PaymentLinkDto.
• Added a new Jest test for fetching a payment link by id (success + non-200 failure case).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
test/payment_links/get-by-id.test.ts	Adds coverage for paymentLinks.getById success and error handling.
src/v0/payment_links.ts	Extends payment-link DTO/query types and modifies getById return typing/shape.

Suppressed comments (2)

src/v0/payment_links.ts:332

• getById now returns the raw API envelope ({ msg, count, results }) which is a breaking change from the previous Promise<PaymentLinkDto> signature and is inconsistent with other v0 “get one” handlers that return the first result as data (e.g. src/v0/payment_options.ts:137-150). A safer approach is to keep returning a single PaymentLinkDto and extract it from response.data.results[0].

This issue also appears on line 339 of the same file.

  async getById (id: string): Promise<PaymentLinkDetailResponse> {
    try {
      const base = this.uriHelper.generateBaseUri()
      const uri = `${base}/${id}`
      const response = await this.http.getClient().get(uri)

src/v0/payment_links.ts:341

• The catch block re-wraps PaymentLinksGetByIdFailed instances, which can drop useful context like the original status (thrown above) and changes the stack. Several other handlers rethrow the original error when it’s already the right type (e.g. src/v0/integration_partners.ts:111-114).

    } catch (error: any) {
      throw new PaymentLinksGetByIdFailed(error.message, { error })
    }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/v0/payment_links.ts:334

• getById currently returns the raw API envelope ({ msg, count, results }) as PaymentLinkDetailResponse. This is inconsistent with the rest of this handler (which typically unwraps results[0] for single-entity endpoints) and causes the new test to mock an envelope but assert a single PaymentLinkDto. Consider returning the first result (and falling back to response.data for backward compatibility) and keep the method return type as PaymentLinkDto.

  async getById (id: string): Promise<PaymentLinkDetailResponse> {
    try {
      const base = this.uriHelper.generateBaseUri()
      const uri = `${base}/${id}`
      const response = await this.http.getClient().get(uri)

test/payment_links/get-by-id.test.ts:42

• The test name says it "returns the extended detail envelope", but the assertion expects a single payment-link object. Either the name or the assertion should be updated so the test intent matches what is being validated.

  it('returns the extended detail envelope', async () => {

src/v0/payment_links.ts:16

• PaymentLinkStatus previously included values like 'open'/'closed'. Removing them is a breaking type change for SDK consumers (even if the backend no longer emits them). If backward compatibility is desired, keep the previous literals and add the new ones.

declare type PaymentLinkStatus = 'sent' | 'paid' | 'expired' | 'authorized' | 'cancelled' | 'refunded' | 'failed'