-
Notifications
You must be signed in to change notification settings - Fork 0
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
ACP-3507 APIs to enable projects embed payment elements to frontends based on Glue API #15
Conversation
…lugin to still confirm the pre-order payment.
…d payment page when we have a pre-order payment.
src/Spryker/Zed/AppPayment/Business/AppPaymentFacadeInterface.php
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/Payment/Method/PaymentMethod.php
Outdated
Show resolved
Hide resolved
…entMethod message.
…p-3507-investigate-how-the-apis-to-enable-projects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built
…er payment was confirmed.
src/Spryker/Zed/AppPayment/Business/AppPaymentFacadeInterface.php
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Persistence/Propel/Schema/spy_app_payment.schema.xml
Show resolved
Hide resolved
tests/SprykerTest/Glue/AppPaymentBackendApi/RestApi/ConfirmPreOrderPaymentApiTest.php
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/Payment/PreOrder/PaymentPreOrder.php
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/AppPaymentFacadeInterface.php
Outdated
Show resolved
Hide resolved
…jects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built' of https://github.com/spryker/app-payment into feature/acp-3507-investigate-how-the-apis-to-enable-projects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built
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.
.
src/Spryker/Zed/AppPayment/Persistence/Propel/Schema/spy_app_payment.schema.xml
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Persistence/Propel/Schema/spy_app_payment.schema.xml
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/AppPaymentFacadeInterface.php
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/Payment/Initialize/PaymentInitializer.php
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/Payment/Initialize/PaymentInitializer.php
Outdated
Show resolved
Hide resolved
src/Spryker/Zed/AppPayment/Business/Payment/PreOrder/PaymentPreOrder.php
Show resolved
Hide resolved
protected function addPaymentMethod(PaymentMethodTransfer $paymentMethodTransfer, AppConfigTransfer $appConfigTransfer): void | ||
{ | ||
// Add the passed configuration to the default configuration. | ||
$paymentMethodAppConfigurationTransfer = $this->getDefaultPaymentMethodAppConfiguration(); |
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.
it looks "too hidden" from the app developer.
so a developer even don't understand that default API URLs (/private) will be sent to SCOS, even no ability to define/overwrite them from the plaform plugin.
What if the app developer should use this method explicitly inside the plugin and have the ability to overwrite URLs?
e.g. via AppPaymentConfig->getDefaultPaymentMethodAppConfiguration()
.
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.
Let's implement it when it gets requested. The point of this is that these packages provide these endpoints so a developer does not need to implement or even know them.
Documentation will help here. I added a more precise one for devs to the README.md
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.
My main concern is as an app developer I cannot change URLs... Maybe it won't be used, but it makes me think that everything is hardcoded in the package and to change it the only way is overwrite methods :)
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.
We are the developers and if we see the need for being able to change we can implement.
…jects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built' of https://github.com/spryker/app-payment into feature/acp-3507-investigate-how-the-apis-to-enable-projects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #15 +/- ##
=========================================
Coverage ? 98.86%
Complexity ? 403
=========================================
Files ? 61
Lines ? 1678
Branches ? 0
=========================================
Hits ? 1659
Misses ? 19
Partials ? 0
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
…jects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built' of github.com:spryker/app-payment into feature/acp-3507-investigate-how-the-apis-to-enable-projects-embed-payment-elements-to-yves-or-in-headless-scenario-should-be-built
Developer(s): @stereomon
Ticket: https://spryker.atlassian.net/browse/ACP-3507
Release Group: https://release.spryker.com/release-groups/view/5558
merge: merge
Release Table
Module AppPayment
Change log
Improvements