I have a doubt about stripe subscriptions when using them with connect accounts.
I want to allow my clients to create subscriptions for a product set up by seller. I have seen how to set up the connect account and the application fee for my business, and here comes my question.
I also offer some extra service that is not related to the merchant so the price of these services should go to my business without any repercusion to the merchant but as far as i have seen the application fee goes to the subscription and not per item.
Maybe i could create 2 subscriptions to achieve this, but if i'm right it will create multiple charges on each billing cycle and same with the invoices.
Is there any way to tie several subscriptions or apply a fee to a specific subscription item?
Thanks a lot in advance
No, what your asking is not supported. Your options are:
Create multiple subscriptions (docs), but as you noted this will involve multiple charges
Set an explicit application_fee_amount on each Invoice that is created, based on your business rules (docs)
Create manual transfers for the correct amount after invoice payment events, similar to "separate charge & transfers" (docs)
Option 3 is fairly advanced, and I would not recommend it unless the first two don't meet your needs.
Related
I'm trying to understand how to develop and manage microservice using Spring-Boot.
In my situation I'm managing a Restaurant and its Orders, having a List of Products and a order-level DiscountCode. The Products can have their own priced discounted (the owner of the restaurant can set as true the discountedPrice of the product and even let apply the discountcode for the entire order).
The part on what i am struggling on is the following:
How should I manage the validation for the Order? When an order has been created it should check using the other micro-services to make the order completed and valid to be processed.
The steps are:
Order created
Verify the products and its price and if they are discounted as passed by the FE
Verify the existence of the discountCode and apply it to the order
Should I create a different component that receives the order created and validate them asynchronously (using RabbitMQ) and getting the information from the other microservices?
Thanks in advice
That's a difficult question, because we did not knwo the domain and the existing services.
Each service should be responible for its own validation. To check if the discount is valid I would prefer that the Discount-Service should do the validation.
If it is same as the order service, the order service should get back the object and validate it after getting the prices.
But it's up to you and your domain.
This is more of a general question regarding the storage and retrieval of payment information for web commerce applications
Our current approach is to have the user enter their payment details after a redirect on a 3rd party web form, similar to what one might do with PayPal.
In order to make it easier for repeat orders, obviously involves storing payment information details, such as credit card numbers, PII information.
Since this has serious security implications, I am wondering what the general accepted best practices are. Is it basically recommended to handle all of this with other tools such as Stripe? Or have others gone with in-house solution ?
For reference, we are working with Java Servlets/JSP.
Your question is rather wide-ranging, and "best practice" is often another word for personal preference and prejudice.
However...
In most countries, to process credit card details requires you to have an arrangement with your bank (often called "cardholder not present"), and the bank will impose fairly strict security requirements on you when you take up that arrangement. In the UK, these requirements are known as "Payment Card Industry Data Security Standard (PCI DSS)".
There are varying options here - a large online store may invest in storing payment details on their infrastructure, but the cost for meeting the required security standards is significant.
You can also work through a payment gateway - an intermediary company which manages the interaction with the banks. They usually have several different integration options - from "Paypal-like" redirects to an API which allows you to collect the credit card data, and pass that through an API to verify payment. Many payment gateways allow you to store the payment details on their infrastructure (which is PCI compliant), and retrieve a token for future payments.
The process is something like:
customer places first order
customer enters payment details
payment gateway verifies payment details
payment gateway collects payment
payment gateway stores payment details
payment gateway sends token to website
website stores payment token with customer profile
customer places second order
website retrieves payment token
website asks "use previous payment details"
customer agrees
website sends token to payment gateway
payment gateway retrieves payment details
payment gateway collects payment
payment gateway tells website payment succeeded
The general answer for this question is NO, don't store anything. Let's 3rd party payment gateway like Paypal do it for you.
It's not only about security (which you will likely do wrong), it also has to deal with regulations, such as the right to store sensitive data such as credit card.
An alternative, very-risky-and-should-be-avoided answer is to store it in browser's session storage. As for this answer, session storage is reasonably secure. Remember to use HTTPS and have XSS prevention in place. But again, this is not recommended by me.
I am working on a project which is using micro-services architecture.
There is two services:
UserAPI : all thing related to user come here.
OMS : All things related to Order Come here.
I need to provide orders based on following filter :
By User Id
By Date
By Status
By User Phone Number
mix of above
So i create an API
path/orders?date=12/11/2016&status=delivered&phone=1111111111
Now i need to provide Orders for User by user ID. So which is good rest design:
Add user ID in query param in existing API like path/orders?user_id=1
Create a Separate API path user/{user_id}/orders
Both of your options are OK. But there are different semantics.
path/orders?user_id=1
This is looking up by orders. Orders maybe looked up for example to do some statistical analysis. The orders can be filtered by different parameters, the user id being one of them. For this (when the orders is the main interest) the above URI strategy is fine.
Now on the other hand you may want to look up a user and see their orders. Maybe to do some analysis on their ordering habits. Here you want user information along with their orders. This is where your second URI scheme would be better
user/{user_id}/orders
These are the orders that belong to the user. So it is a relationship. This is where this URI scheme works better.
So really there's nothing wrong with having both options. You just need to follow the semantics of when each should be used.
I came across a serious issue with our payment workflow today.
Once a payment is completed, two things happen:
the user gets redirected to a success-page on our server, the redirect also appends the payment id
the payment provider sends a payment notification including the payment id to our server
When the user gets redirected to the success-page we check whether a payment with the payment id exists. If this is not the case we create a pending payment that we can show to him.
When the payment provider sends a payment notification we check whether there exists a pending payment with the payment id and set it to active, if no payment exists we just create an active one.
Here's the problem: Both events can (and did!) happen simultaniously such that both routines did not find an existing payment and so two payments got created. One pending and one active.
Is there a good way to circumvent this behaviour by possibly using locks or something?
I'm using the default Ebean ORM on a java based play 2.1.0 with a MySQL db.
This isn't a Play thing at all. My advice is to not use locks. If you do then you will limit the scalability of your application.
You need to cope with this race condition. Race conditions will always occur and there's nothing you can do to prevent them. So, embrace them.
In the instance you describe its sounds like the pending state should be overridden by the active state if both exist in the database.
I don't know if this answers your question or not, but here is a link to the Ebean transactions page.
I am working on a large Java EE web-app with CRM functionalit and we are looking for a security approach/library/solution/anything. Basic role-based security won't work since access control must be based on both role and hierarchy, but must be optionally customisable per document. Because there will be confidential and proprietary information stored, it is a requirement that the security works properly.
Example: To use department store, shelf stalkers stockers can create reports that other stockers can read only if they are in the same department. Now their department manager can read/write/update/delete all reports written by stockers and write reports that all others department managers can read but not see reports of store managers, etc, whom the district managers can r/w/u/d etc. Now, the complications: people at higher levels can make things visible to people at lower levels, either to individuals (department writes document to several specific stockers) users or everyone below them (store manager writes a memo to the entire store) or any permutation you can imagine. Also, individuals can create reports that their peers cannot see or they can choose grant access to store stockers in other districts etc.
We are considering an ACL with one permission per entity, but are worried about the large number of records that would create. Even if only a report was readable to everyone else in a department of 30 and every person above them [in the chain of command], creating a single report would require ~40 records! With 1 report per week per user that is 2000 permissions per user per year. 1,500 users means over 3,000,000 permissions per year.
It seems like a rule-engine based approach would be nice, but I have not seen any blogs or articles mentioning that approach so we're hesitant to that approach.
We are also considering some ACL/rule home-brew hybrid where you could grant permission to a department id with a discriminator of "manager" or "stockers" etc to subselect, but are worried that checking for all possible permissions (you could be granted permission specifically by another user, you have permission as a memeber of your department, you could have permission as a member of a store, or of district) sounds like an error-prone tedious nightmare.
What is the best approach for our application?
You could look at using Spring Security and ACL's - the nice thing about Springs ACL implementation is it is implemented with AoP it should be easier to integrate.
It sounds like your security requirements are quite complicated - off the top of my head I dont know how you'd implement this.. but you can reduce the number of records required by creating ACL's against your object hierarchy and having objects 'inherit' permissions from parent objects. You grant a user read permissions to the parent Department of a Report - so they would inherit read access to the child reports of that department. Alternatively a Manager might have read and update permissions on the Department. The key to all this is how your java object model has been structured.
I have had a similar situation in a system where there were thousands of articles in an object hierarchy of Business Unit -- Publication -- Issue -- Article. You can have hierarchys of ACL's - so in my system - users that had C/R/W permissions to a particular business unit, inherited permissions on all child objects in the hierarchy.
In my opinion Customization + Complexity = JBoss Drools, I don't have much experience using this technology but I believe it would be worth a look in your case, check out the latest drools samples at: http://blog.athico.com/2011/04/try-drools-example-in-less-than-minute.html