In the docs, when building the MaskedWalletRequest they say:
At this point, you won't have the user's chosen shipping address, so
you'll need to create an estimate of the shipping costs and tax. If
you set the shopping cart as shown below (highly recommended), make
sure the cart total matches the sum of the line items added to the
cart.
link
Later when I create my FullWalletRequest I have to pass in a Cart*. So why would I want to add a Cart to my MaskedWalletRequest? Why is it "highly recommended"?
*If I don't pass in a Cart I'll get WalletConstants.ERROR_CODE_INVALID_PARAMETERS
As Android Pay documentation states, Google highly recommends setting the shopping cart in the Masked Wallet request. Having additional line item information at this point of the transaction greatly increases Google's fraud detection capabilities, and also lets you provide more detailed purchase information to your users.
At this point, you won't have the user's chosen shipping address from Android Pay, so you must create an estimate of the shipping costs and tax.
Related
I'm using the EasyPost API and I'm having a few blockers along the way. I want to create a Shipment and buy insurance at the same time, but it seems that the API wants you to first purchase the Shipment (the postage), then to buy the insurance, as per this doc: https://www.easypost.com/docs/api/java#shipping-insurance
But the doc of Create Shipment says differently, it takes an insurance amount: https://www.easypost.com/docs/api/java#shipment-object
I came to the conclusion that that the API cannot process them together, even though the Create Shipment says differently, you have to buy the label first and then buy the insurance. But this is counterintuitive for my workflow, I want to use one form to allow the user to set the addresses, the parcel, select if the shipment is insured or not, and buy the label + the insurance in one transaction au lieu of doing two transactions (the postage and the insurance).
Purchasing a shipment is typically a 2 step process:
Create shipment (rates are returned)
Buy shipment (with selected rate)
You can see that insurance amount can be declared when making the buy call. After you have purchased a production shipment, you can confirm that insurance was successfully charged by looking at the objects returned in the "fees" array of the shipment.
I have an invoice with 500USD after that I have the journal entry with 500USD. While I'm doing payment I can add the amount to 800USD so on odoo it will give an option to keep open or Mark As fully paid. So I'm choosing the keep open option So as per this case odoo has to keep the invoice in an open state with 300USD remaining amount but why it should change the state to pay with the same invoice amount?
So anyone can suggest the functional thing with this case?
Yes you're right this is the default functionality of the Odoo and it is extremely cool thing in Odoo because Odoo is managing outstanding payments of our customer very effectively.
Important Point
If there is an invoice of 500USD and I registered 800USD yes it is
right thing to close the invoice 500USD because customer has paid it.
But what about the remaining 300USD. Odoo has cool feature to manage
outstanding payments. Here you can see in attached image.
I've an invoice of 125USD and I registered 200USD (200-125=65USD) then see how Odoo manage it for my important customer.
I'm using Stripe Checkout to create a subscription in Stripe Billing. Checkout also auto creates the Stripe customer object.
How can I add right right VAT rate based on where the customer is based? The customer should be able to see the price both including and excluding VAT/GST both in the checkout session itself and on the invoice.
The "create subscription" API call allows you to set the field "default_tax_rates" which sounds like what I need, but the problem is that with Stripe Checkout the subscription (and the customer object) are created automatically by Stripe Checkout so I cannot explicitly pass parameters to these creation calls.
I know how to calculate the VAT rate and I don't want to integrate with another third party vendor just for tax, so I'm not looking for something like Quaderno or Taxamo.
How do people solve this problem? I'm starting to think that maybe I should have integrated with Chargebee instead of Stripe :-(
I'm having that same issue.
Stripe support informed me that Checkout does not support the legacy tax percentage or the new Tax Rates object.
Checkout charges only the exact amount.
On recommendation from stripe I will calculate the tax and charge that as a separate line item.
That way the correct amount is charged and the VAT is clearly visible to the customer.
I'm also creating subscriptions and there I will show the amount incl. VAT. and post fix the plan name with 'incl. VAT' to make it clear to the customer.
After the checkout flow completes I will try to add the Tax Rate to the invoice and subscription as 'Inclusive' using the API. I'm not sure that will work as I think, but we will see.
Check this out https://stripe.com/docs/payments/checkout/taxes
Seems like you're right about the Stripe checkout. Can't be added there.
Adding VAT as Inclusive won't help you, because Inclusive means it's already calculated into the price. Although this can be used to add the VAT to the price (in most cases it's 20%) and set the VAT as Inclusive. But this hack won't work for everybody, though.
I found this to be helpful and it works with Checkout.
https://dominik.sumer.dev/blog/stripe-checkout-eu-vat
You collect the Country and VAT number before creating the customer and checkout, and you add dynamic tax rates prepared via the API in advance.
I am trying to refactor a legacy order handling and stock system with into a cleaner service oriented event-driven architecture. However, I am having some difficulty deciding what service should be responsible for the reservation/allocation of stock.
A brief overview of the current system
Sales orders are placed with us via third party system but we do not necessarily have all order lines in stock.
If an order item is in stock then we allocate/reserve the stock for that order straight away.
However, if we do not have enough stock then we procure the stock from our suppliers via a purchasing system.
When the item arrives from the supplier, the system will search through all open sales orders for the item and reserve/allocate the available stock to them, prioritising by sales order date. ***
I have already identified two services that I think need to be developed
Sales - Responsible for receiving the sales order and inserting into the database. Has domain entities such as Order, OrderLine etc.
Inventory - Responsible for keeping track of how much stock is available in our warehouse. Has domain entities such as StockItem.
However, as the allocation/reservation of stock concerns both inventory and sales I am not sure where the behaviour in point 2 above should be put.
I welcome any help or thoughts on this.
I think you have 2 BCs (bounded contexts): Inventory and Sales. For the integration between them I would probably go for domain events approach.
When a new item arrives at the warehouse, the Inventory BC increments the stock for the item, and publish an event.
Sales BC subscribes to the event, and it updates the opened sales that are waiting for the stock item.
So, behaviour of "point 2" are shared by both BC:
Sales BC search for opened orders waiting for that item. And then it asks Inventory BC to get the number of items it needs (this request is synchronous) and close the order.
Inventory BC receives the request and decrements the stock for the item.
However, as the allocation/reservation of stock concerns both inventory and sales I am not sure where the behaviour in point 2 above should be put.
I've been thinking about this problem (purely academically), and my current conclusion is that reservation management belongs with the inventory system. That keeps the stock source (the loading of items procured from your suppliers) and the stock sink (fulfillment of orders) together.
So the inventory system caches its own copy of the data required to fill the order (allowing it to work autonomously). It should be able to make progress as soon as it is informed that the suppliers have provided new inventory, even if the sales system happens to be down for maintenance.
You mentioned SOA and NServiceBus, so my initial thought was that you've attended Udi Dahan his ADSD training? I'll assume you have. With that, I'll try to answer your question.
So far I don't have a lot of information. But with what we have, I figured we need these properties to store all that you mentioned.
ProductId, one for each available product
InventoryTotal, attached to a ProductId. This number goes up and down
OrderId, to create an order
OrderDate, to make sure we can find the order that should receive incoming stock first.
If you have an OrderId, you can attach one or more ProductId to create an actual order. Different ways of storing this technically. Maybe in a relational database with Order and OrderLine tables, or possibly in a DocumentDb where everything is stored in a single document. That's totally irrelevant at this point.
Assuming we need 4 attributes, I'm not sure why we would create more than 1 service to split this up? This might change when we have more information, but at this moment I don't see the need.
If you want to discuss this, contact us at support#particular.net, mention my name and we can continue the conversation.
You are talking about loosely coupled domain apps, managing your sales orders, managing your inventory and managing your purchase orders.
Inventory must always be up to date, in order to not sell what you can't deliver. So PO en SO app should both talk to inventory via synchronous (inventory) services. To keep everything consistent, events on purchasing side, like receiving less than you expected for a PO, will have an impact on any SO already assigning quantity of that PO, as persisted in inventory. So the same PO pcs for example, in which the event of receiving less as expected, is registered, should synchronously update inventory, to update the quantity available for SOs to assign from, and publish an event, to be picked up, asynchronously, in the So app, so that the user can be notified and talk relevant action. Etc.
Do I have to do this server side with a custom payment button instead of their (beautiful) default one? Or can I just do some logic with the javascript (price*amount) or will it not work with their custom token thingy they generate? I'm using their Java api with Google Appengine, if that makes a difference.
To add to the other posts, here's a concrete example of how I'm doing it.
On the 'pay now' page with the default button, pass in the amount. One way I'm doing this is from a form on a previous page.
Parse this amount, e.g.
<?php
...
$data_amount = $_POST['data_amount'];
...
?>
And then use this amount as a value in the JS script which actually process the charge
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
...
data-amount="<?php echo $data_amount; ?>"
...
</script>
Good luck!
The quantity and any other information about the items being purchased are irrelevant to the payment gateway, in this case, stripe. All that matters is the payment method (e.g. "visa card ending in 1234"), the amount, the currency and the customer.
You don't have to use the stripe provided checkout methods, you can write your own. The stripe examples are extensive and include Java code, though really the concepts are harder than the code itself (and the concepts aren't that hard). The token represents the payment method/customer and has nothing to do with the amount being charged.
You can do whatever you like to implement the product / quantity / price calculations. The Stripe API simply expects your server-side to make a "charge" passing the card (or customer) token, and supplying an amount and a currency. (There are a bunch of optional parameters too ...)
The "token thingy" does not contain an information about the payment itself.
I've not attempted to use Stripe myself. The above is based on a cursory (10 minute) reading of the documentation. But there are copious examples that you can find via the Stripe "Documentation" menu, including (Java) examples of what you need to do on the server side.
As the other folks have mentioned, the token doesn't contain quantity/charge amount info. The charge amount goes into the charge object.
Now, as far as additional info, particularly if you're coming from the classic PayPal world where you have quantities and so forth, or even if not but your purpose requires the back-end to know the extra detail, most (but not all) Stripe objects allow you to store key-value pairs in the optional 'metadata'.
If you're rolling up a cost (particularly if you're doing tax or other computations to get the total) you'll probably want to stuff the essentials (quantity, unit price, tax, itemized list, etc) into that block to be able to sanity-check and/or extract the details later on in the processing flow.
The Stripe docs are quite well done; click 'Java' at the top of the example column and you'll get cut-and-paste examples (for the most part).