-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Migrated Mollie to Payments API #3603
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrated Mollie to Payments API #3603
Conversation
@martijnvdbrug is attempting to deploy a commit to the Vendure Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughThe codebase has been refactored to migrate the Mollie payment integration from using Mollie's Orders API to the Payments API. All relevant logic, type definitions, helpers, and test fixtures have been updated accordingly. The Mollie API client dependency has been upgraded to v4, and tests and documentation have been revised to reflect these changes. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant VendureServer
participant MollieAPI
Client->>VendureServer: createMolliePaymentIntent(input)
VendureServer->>MollieAPI: Create Payment (Payments API)
MollieAPI-->>VendureServer: Payment Created (paymentId, status, etc.)
VendureServer-->>Client: Payment Intent Result (redirect URL, paymentId)
MollieAPI-)VendureServer: Webhook (paymentId, status update)
VendureServer->>VendureServer: handleMollieStatusUpdate(paymentId)
VendureServer->>MollieAPI: Fetch Payment Details
MollieAPI-->>VendureServer: Payment Details (status, metadata)
VendureServer->>VendureServer: Update Order/Payment State
Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes were found. All modifications are directly related to the objectives of migrating to the Mollie Payments API and upgrading the Mollie client to v4. Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm error Exit handler never called! 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (4)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
'and you need to manually settle payments to get paid.', | ||
}, | ||
], | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Autocapture is now handled by Mollie, and we can pass it in via the createMolliePaymentIntent
mutation.
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🔭 Outside diff range comments (1)
packages/payments-plugin/src/mollie/mollie.plugin.ts (1)
82-82
: Documentation contradicts the API migration.The comment states "This plugin uses the Order API from Mollie, not the Payments API" but this PR migrates to the Payments API. This documentation needs to be updated.
- * This plugin uses the Order API from Mollie, not the Payments API. + * This plugin uses the Payments API from Mollie.
🧹 Nitpick comments (3)
packages/payments-plugin/e2e/mollie-dev-server.ts (2)
102-107
: Locale parameter addition aligns with PR objectives.The explicit locale specification (
'nl_NL'
) correctly implements the migration away from locale guessing based on order country, as mentioned in the PR description.Consider adding a comment explaining why
immediateCapture
is commented out:+ // immediateCapture: true, // TODO: Enable for auto-capture testing - // immediateCapture: true,
111-126
: Enhanced test scenario for payment intent handling.The additional test logic with a second payment intent and delay provides better coverage for the payment-based workflow.
Consider adding a comment explaining the test scenario purpose:
+ // Test scenario: Create multiple payment intents for the same order to verify payment handling // Add another item to the order
packages/payments-plugin/src/mollie/mollie.service.ts (1)
208-213
: Consider enhancing error message for missing checkout URL.The error message could be more descriptive to help with debugging.
const molliePayment = await mollieClient.payments.create(paymentInput); Logger.info(`Created Mollie payment ${String(molliePayment.id)} for order ${order.code}`, loggerCtx); const url = molliePayment.getCheckouturl(""); if (!url) { - throw Error('Unable to getCheckouturl("") from Mollie payment'); + throw Error(`Unable to getCheckouturl("") from Mollie payment ${molliePayment.id} for order ${order.code}. Payment status: ${molliePayment.status}`); }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.json
is excluded by!**/package-lock.json
📒 Files selected for processing (14)
packages/payments-plugin/e2e/fixtures/mollie-mock-data.ts
(1 hunks)packages/payments-plugin/e2e/mollie-dev-server.ts
(2 hunks)packages/payments-plugin/e2e/mollie-payment.e2e-spec.ts
(24 hunks)packages/payments-plugin/e2e/stripe-payment.e2e-spec.ts
(1 hunks)packages/payments-plugin/package.json
(2 hunks)packages/payments-plugin/src/mollie/api-extensions.ts
(3 hunks)packages/payments-plugin/src/mollie/index.ts
(1 hunks)packages/payments-plugin/src/mollie/mollie.controller.ts
(2 hunks)packages/payments-plugin/src/mollie/mollie.handler.ts
(3 hunks)packages/payments-plugin/src/mollie/mollie.helpers.ts
(4 hunks)packages/payments-plugin/src/mollie/mollie.plugin.ts
(5 hunks)packages/payments-plugin/src/mollie/mollie.service.ts
(10 hunks)packages/payments-plugin/src/mollie/types.ts
(1 hunks)packages/payments-plugin/src/stripe/metadata-sanitize.ts
(1 hunks)
🧰 Additional context used
🪛 Biome (1.9.4)
packages/payments-plugin/e2e/mollie-payment.e2e-spec.ts
[error] 339-339: Unsafe usage of optional chaining.
If it short-circuits with 'undefined' the evaluation will throw TypeError here:
(lint/correctness/noUnsafeOptionalChaining)
🔇 Additional comments (34)
packages/payments-plugin/src/stripe/metadata-sanitize.ts (1)
23-23
: Remove redundant type assertion
The precedingtypeof metadata[keyName] !== 'string'
guard already narrows the value to a string, so accessing.length
directly is safe and the explicit cast can be dropped to simplify the expression.packages/payments-plugin/e2e/stripe-payment.e2e-spec.ts (1)
255-255
: Verify if this change is intentionally part of the Mollie migration PR.This change converts the
requestOptions
function from async to synchronous, which is technically correct since it doesn't perform any async operations. However, this appears unrelated to the Mollie API migration described in the PR objectives.Likely an incorrect or invalid review comment.
packages/payments-plugin/src/mollie/types.ts (1)
1-10
: Well-structured interface for the payment-centric approach.The
MolliePaymentMetadata
interface appropriately reflects the migration from Mollie orders to payments. The type definitions are clear and the status field correctly represents payment states.packages/payments-plugin/package.json (2)
31-31
: Dependency upgrade aligns with PR objectives.The update to Mollie API client v4.x correctly implements the breaking change mentioned in the PR description, requiring plugin consumers to install
@mollie/api-client@4.3.3
.
50-50
: Dev dependency version is appropriate.The specific version
^4.3.3
provides good compatibility while allowing patch updates.packages/payments-plugin/src/mollie/mollie.controller.ts (2)
2-2
: Import reordering is cosmetic.The import statement was reordered without functional changes.
32-32
: Correct migration from orderId to paymentId.This change properly reflects the shift from Mollie orders to payments API. The webhook now correctly passes the payment ID to the service layer.
packages/payments-plugin/e2e/mollie-dev-server.ts (1)
19-19
: Clean import simplification.Removing unused coupon creation helpers improves code clarity.
packages/payments-plugin/e2e/fixtures/mollie-mock-data.ts (1)
1-81
: LGTM! Well-structured mock data for comprehensive testing.The mock data file provides realistic and comprehensive test fixtures that properly mirror Mollie's API response structure, including HAL-formatted links and proper data types. This centralized approach improves test maintainability.
packages/payments-plugin/src/mollie/api-extensions.ts (2)
26-37
: LGTM! Well-documented schema extensions for enhanced payment control.The new
immediateCapture
andlocale
fields provide important functionality for the Payments API migration. The documentation clearly explains the 28-day expiration for manual capture and provides helpful links to Mollie's documentation.
57-57
: Clean template literal formatting improvement.The formatting change to use template literals for schema extensions improves code readability.
Also applies to: 88-88
packages/payments-plugin/src/mollie/index.ts (1)
1-3
: Clean export restructuring aligns with API migration.The reordering of exports and removal of
getLocale
export correctly reflects the migration away from automatic locale detection to explicit locale specification in the new API.packages/payments-plugin/src/mollie/mollie.plugin.ts (5)
1-1
: Fixed import path removes erroneous path segment.The import path correction properly removes the incorrect
src
segment from the ListParameters import.
11-11
: Clean import order improvement.Swapping the order to import admin extensions before shop extensions provides a more logical organization.
107-110
: Setup instructions properly updated for the new API.The removal of the database migration step and renumbering of setup instructions correctly reflects the migration to the Payments API.
121-125
: Enhanced mutation example with new optional parameters.The expanded GraphQL mutation example properly documents the new
locale
andimmediateCapture
parameters with helpful comments explaining their optional nature.
173-181
: Improved pay-later payment documentation.The clarified explanation of immediate vs manual capture, including the 28-day expiration warning and link to Mollie documentation, provides valuable guidance for developers.
packages/payments-plugin/src/mollie/mollie.helpers.ts (4)
1-3
: Import changes correctly reflect migration to Payments API.The updated imports properly shift from order-related types to payment-specific types, maintaining compatibility with global types like Amount and Address.
10-25
: Address mapping function properly updated for Payments API context.The function logic remains correct while the return type annotation and documentation accurately reflect the migration to payment-specific types.
28-79
: Excellent refactoring to payment lines with proper negative price handling.The function rename and property changes correctly align with the Payments API. The addition of
type: 'store_credit'
for negative unit prices (surcharges and already paid amounts) is a smart solution to ensure Mollie accepts negative values. The consistent use ofdescription
instead ofname
follows the payment API schema.
81-106
: Currency and tax calculation utilities correctly unchanged.These utility functions handle mathematical operations independent of the API context, so keeping them unchanged is appropriate and maintains consistency in amount handling across the migration.
packages/payments-plugin/src/mollie/mollie.handler.ts (3)
88-109
: Well-implemented capture polling with retry logic.The implementation correctly handles asynchronous capture operations with a reasonable retry strategy (10 attempts × 500ms = 5 seconds total). The error handling differentiates between failed captures and timeouts, providing clear error messages.
52-77
: Correct implementation of payment creation with new metadata structure.The method properly validates the payment status and uses the new MolliePaymentMetadata type with the correct paymentId field instead of orderId.
114-124
: Proper migration to Payments API for refunds.The refund logic correctly uses the Payments API endpoints and maintains proper error handling.
packages/payments-plugin/e2e/mollie-payment.e2e-spec.ts (4)
10-10
: Good refactoring to centralize mock data.Moving mock data to a dedicated fixture file and using it consistently throughout tests improves maintainability and reduces duplication.
Also applies to: 34-34, 80-80
223-244
: Well-structured test validations for payment request.The test properly validates all critical fields of the Mollie payment request including description, redirectUrl, locale, and captureMode. The assertion that default captureMode is 'automatic' aligns with the expected behavior.
466-486
: Good test coverage for duplicate payment scenario.The test properly validates error handling when an order is paid multiple times with different transaction IDs. The error message includes both order code and payment ID which aids in debugging.
552-645
: Comprehensive test coverage for manual capture flow.The new test suite thoroughly covers the manual capture functionality including:
- Creating payment intent with
immediateCapture: false
- Handling authorized payments
- Settlement via mutation with proper capture API mocking
This aligns well with the PR objective of supporting pay-later payment methods.
packages/payments-plugin/src/mollie/mollie.service.ts (6)
2-7
: Proper type updates for Payments API migration.The import and type changes correctly reflect the migration from Orders API to Payments API, including the new MolliePaymentMetadata type and updated OrderStatusInput interface.
Also applies to: 40-42, 44-47
94-105
: Good addition of payment method eligibility check.The eligibility check prevents creating payment intents with ineligible payment methods, providing better error handling upfront.
240-252
: Excellent handling of language context preservation.The code properly extracts and preserves the original languageCode from payment metadata, ensuring the correct language context is maintained throughout the order processing flow.
275-295
: Comprehensive error handling for payment edge cases.The implementation properly handles duplicate payments and payments for cancelled orders with clear error messages that include relevant IDs for debugging.
350-389
: Well-structured payment metadata handling.The addPayment method properly constructs and stores comprehensive Mollie payment metadata, which will be useful for debugging and payment tracking.
469-492
: Efficient order fetching with proper relation loading.The getOrder method properly handles both explicit order ID and active order scenarios while loading all necessary relations upfront, preventing N+1 query issues.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
d0db5cb
into
vendure-ecommerce:minor
Thank you @martijnvdbrug 🙏 |
Description
Migrated the Mollie plugin from using the Orders API to the Payments API, because the orders API is deprecated. See the Mollie docs for more info.
Breaking changes
@mollie/api-client@4.3.3
Checklist
📌 Always:
👍 Most of the time:
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Refactor
Chores