Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #7944

Re: Refunding PayPal payments for a SaaS

Show all headers | View raw

Julio Di Egidio wrote:

> On Wednesday, July 26, 2017 at 12:37:16 AM UTC+2, Victor Porton wrote:
>> Julio Di Egidio wrote:
>> > On Tuesday, July 25, 2017 at 6:21:25 PM UTC+2, Victor Porton wrote:
>> >> We are building a SaaS paid with PayPal.
>> >> 
>> >> We process PayPal's notifications for payments, subscriptions, and
>> >> canceling subscriptions.
>> >> 
>> >> Should we also process refunds (automatically canceling a service if
>> >> its payment was refunded)?
>> >> 
>> >> There is a reason not to: Refunds may happen in the case we do an
>> >> error in our payment processing system or a race condition. In this
>> >> case refund should not cancel the service, for obvious reasons.
>> >> 
>> >> What are further arguments pro and counter to cancel or not to cancel
>> >> a service automatically in the case of a refund?
>> > 
>> > The logic of payments/refunds and the logic of services should be
>> > independent.  On a side, you can have up to complicated payment/refund
>> > schemes including discounts and offers.  On the other, you can have
>> > active
>> > vs suspended vs cancelled services, and so on.  In general, the fact
>> > that some (plural) payments/refunds may (or may not) correspond to some
>> > (plural) service status changes is in fact a higher-level relationship,
>> > call it a "user transaction" (you may find a better name/abstraction
>> > more suited to your domain).
>> 
>> Even if so,
> 
> There is no contrast between what I have explained, which is in general,
> and the specific problem you are trying to solve, which might just end
> up simplifying relative to the general case.  In general, a use case
> splits into tasks and sub-tasks, each of which in turn may leverage some
> components or services over possibly a collection of business objects:
> and you are essentially talking about flattening the whole hierarchy,
> which is sensible if and only if the hierarchy is flat to begin with...
> 
>> we need to write software which automatically subscribe on
>> payment.  Should it also automatically unsubscribe on refund?
> 
> - Do you mean that your system just receives a notification of payment
> (say, from the finance department's system) upon which it automatically
> will subscribe the corresponding user?
> 
> - Do you mean that your system just receives a notification of refund
> (say, from the finance department's system) upon which it automatically
> will unsubscribe the corresponding user?

Yes.

> If that is *all* that happens in your system, sure go for it, though then
> I cannot really guess why you were having any doubt to begin with: indeed,
> that means that your system just knows nothing about any payments/refunds,
> rather some external system is telling it "subscribe this user" or
> "unsubscribe this user", and that's all there is to it.
> 
> And you are certainly welcome to refine your description and question at
> this point, I have been totally guessing about your actual requirements,
> but my point is more to show you how to think and go about it: this is
> analysis, where ultimately you have to answer your own questions...
> 
> Julio
-- 
Victor Porton - http://portonvictor.org

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Refunding PayPal payments for a SaaS Victor Porton <porton@narod.ru> - 2017-07-25 19:21 +0300
  Re: Refunding PayPal payments for a SaaS Julio Di Egidio <julio@diegidio.name> - 2017-07-25 10:48 -0700
    Re: Refunding PayPal payments for a SaaS Victor Porton <porton@narod.ru> - 2017-07-26 01:37 +0300
      Re: Refunding PayPal payments for a SaaS Julio Di Egidio <julio@diegidio.name> - 2017-07-25 18:20 -0700
        Re: Refunding PayPal payments for a SaaS Victor Porton <porton@narod.ru> - 2017-07-26 15:02 +0300
          Re: Refunding PayPal payments for a SaaS Ed Prochak <edprochak@gmail.com> - 2017-07-26 19:59 -0700

csiph-web