Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Payment type selector template for multiple providers #246

Closed
aaronjudd opened this issue Jan 18, 2015 · 2 comments
Closed

Payment type selector template for multiple providers #246

aaronjudd opened this issue Jan 18, 2015 · 2 comments
Assignees
@aaronjudd
Labels
help wanted For issues that have a clear solution described and are not currently prioritized core team work
Milestone
Payment Workflow

Comments

@aaronjudd
Copy link
Contributor

When there are multiple payment packages enabled, instead of just looping through the payment packages, it would be good to have an alternate display, either an accordion style of selection, or a screen that display payment types/providers allowing the user to choose.
@aaronjudd aaronjudd modified the milestones: v0.2.3, v0.2.4 Jan 18, 2015
@aaronjudd aaronjudd mentioned this issue Jan 18, 2015
Closed
@aaronjudd aaronjudd modified the milestones: Payment Workflow, v0.2.4 Jan 19, 2015
@aaronjudd aaronjudd added ready and removed ui / ux labels Jan 19, 2015
@aaronjudd aaronjudd self-assigned this Jan 21, 2015
@aaronjudd aaronjudd removed their assignment Mar 11, 2015
@aaronjudd aaronjudd added the help wanted For issues that have a clear solution described and are not currently prioritized core team work label Mar 11, 2015
@aldeed
Copy link
Contributor

aldeed commented Mar 11, 2015

To eventually support this accordion idea, paypal express and pro will have to be separated into two different checkout templates, and both will have to be registered. That's fine, but there is also the ability to enable/disable each one, so that would need the ability to register some function that core will call to see whether each should be included in the accordion. The simpler solution, since the APIs are different anyway, would be to have two separate paypal packages, paypal-pro and paypal-express, which can be enabled/disabled separately in the dashboard. Was this approach considered?

@aaronjudd
Copy link
Contributor Author

we did talk about it a little.. in my mind the only factor that leans towards having one package with multiple methods is that we only have one package to maintain, and I think it's a better user experience to just see "paypal" and then pick their configuration from several paypal methods. - other than that you're right - but we could just lay it out within the package like it's multiple packages.

with paypal it's also highly likely you would enable more than one method - I think it would be cleanest to just give each method it's own provides="paymentMethod" template - so it's the same format as all other packages, and have this issue handle the presentation of the options (that said, it still works as a single template/paymentMethod).

@aaronjudd aaronjudd self-assigned this Apr 14, 2015
@aaronjudd aaronjudd removed the ready label Apr 14, 2015
aaronjudd added a commit that referenced this issue Dec 3, 2015
@aaronjudd
initial package registry refactor
bc8ddee 
Changes that refactor the `ReactionCore.registerPackage`
implementation to a more flexible, and structured template
registry. `ReactionCore.registerPackage` moves to server.
package.registry is published to client.

These are not backwards compatible changes.

Updated documentation at docs/packages.md

Initial commit for issue #314

Strategic updates for Issue #273
Strategic updates for Issue #306
Strategic updates for Issue #305
Strategic updates for Issue #246
Strategic updates for Issue #183
Strategic updates for Issue #155
Strategic updates for Issue #16
Strategic updates for Issue #148

Resolves #53
Resolves #308
Resolves #178

*Remaining tasks*

solve undefined error
convert the rest of the payment packages
context sensitive widgets (context?)
update with detailed docs
(document all the existing "provides")
aaronjudd added a commit that referenced this issue Dec 3, 2015
@aaronjudd
completed package-registry-refactor
3de2369 
##package-registry-refactor
Changes that refactor the `ReactionCore.registerPackage`
implementation to a more flexible, and structured template
registry. `ReactionCore.registerPackage` moves to server.
package.registry is published to client.

cycle = Core, Stable, Testing (todo: => correlates package semver)
container = combine multiple registry entries

These are not backwards compatible changes.

Updated documentation at docs/packages.md

Initial commit for issue #314

Strategic updates for Issue #273
Strategic updates for Issue #306
Strategic updates for Issue #305
Strategic updates for Issue #246
Strategic updates for Issue #183
Strategic updates for Issue #155
Strategic updates for Issue #16
Strategic updates for Issue #148
Strategic updates for Issue #146

Resolves #53
Resolves #308
Resolves #178
aaronjudd added a commit that referenced this issue Dec 3, 2015
@aaronjudd
Payment type selector template for multiple providers
6b44385 
- adds a priority value to reactionApp helper
- adds default icon and label from app, can be customized via registry
- resolves #246
- payment label added to en.json `checkoutPayment.{{name}}.label`
- remove meteor timeout on cartWorkflow.paymentMethod (seems to work as
expected now)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aaronjudd aaronjudd

Labels
help wanted For issues that have a clear solution described and are not currently prioritized core team work
Projects
None yet
Milestone
Payment Workflow
Development

No branches or pull requests
2 participants
@aaronjudd @aldeed